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Background  &  Acknowledgments 

This  application  was  developed  under  funding  from  the  Office  of  Naval  Research.  The 
original  work  was  performed  undCT  contract  N00014-93-1-1150,  Susan  Chipman,  Sponsor 
Program  Manager.  Subsequent  vCTsions  (2.6  and  2.7)  and  technical  support  were  provided 
under  contract  N00014-95-1-0782,  Helen  Gigley,  Sponsor  Program  Manage.  The 
simulation  development  system  used,  RIDES,  was  developed  at  Bdiavioral  Technology 
Laboratories  und«’  Air  Force  funding  at  Armstrong  Laboratories,  James  Fleming  Program 
Manager.  RIDES,  in  turn,  is  a  descendent  of  an  earlia  system,  the  Intelligent  Maintenance 
Training  System  (IMTS),  developed  under  funding  from  ONR. 


This  document  supersedes  previous  reports,  ONR  Final  Report  dated  August  1995,  and  A 
Configurable  Task  Environment  for  Learning  Research,  dated  March,  1996. 


Summary 

This  software  provides  a  moderately  realistic  simulation  of  a  shipboard  radar  tracking 
system,  such  as  AEGIS.  The  graphics  resemble  those  provided  on  the  large-saeen  display  of 
the  AEGIS  system,  and  the  commands  which  can  be  issued  are  many  of  those  available  to 
the  decision-makCT  commanding  a  CIC  team.  The  simulated  radar  display  of  air  and  sea 
tracks  are  updated  on  a  real-time  basis,  and  the  display  reflects  movements  of  these  craft  in 
real  time.  Depending  upon  the  scenario  conditions  specified,  the  air  and  sea  craft  may  be 
friendly  cr  hostile,  and  they  may  or  may  not  react  to  actions  taken  by  the  CIC  team.  A  wide 
range  of  atmospheric  and  system  readiness  conditions  can  be  established  for  any  individual 
exCTcise.  In  addition,  the  various  craft  may  be  set  up  to  execute  maneuvers  of  their  own,  i.e., 
not  in  response  to  actions  taken  by  the  CIC  personnel.  The  individual  targets  may  be 
configured  to  r^resent  virtually  any  type  of  craft,  ranging  from  commercial  fishing  vessels, 
private  helicopters,  or  commercial  airliners  to  high-performance  military  aircraft. 

A  unique  feature  of  this  software  is  its  ability  to  be  easily  configured  by  a  non-programmer 
to  simulate  a  wide  range  of  conditions  and  tactical  scenarios.  An  exp^imenter  can  define  any 
number  of  initial  conditions  as  well  as  within-problem  actions  taken  by  the  various  ships  and 
aircraft.  If  desired,  the  system  can  be  directed  to  generate  problem  conditions  automatically, 
so  that  human  participants  or  computer-based  decision  models  can  experience  hundreds  or 
thousands  of  problems  with  v^y  little  configuration  effort  on  the  part  of  the  experimenter. 
The  system  also  supports  research  in  machine  learning,  as  it  can  accept  decisions  of  an 
external  software  system  as  if  those  decisions  were  made  by  a  human  user. 

Finally,  the  system  provides  features  that  can  be  exploited  for  training.  One  such  feature 
allows  expert  tacticians  to  perform  recommended  responses  to  specific  tactical  situations  and 
to  distribute  these  completed  presentations  to  classrooms  or  to  the  fleet  via  floppy  diskette. 
Learners  or  instructors  can  then  r^lay  those  scenarios  at  remote  locations  to  observe  the 
expert  performance,  and  to  attempt  to  emulate  them.  The  ability  to  pause  and  resume,  as  well 
as  control  the  speed  of  the  simulation  further  enables  learners  and  instructors  to  examine 
conditions  and  consido"  alternatives  in  ways  the  true  real-time  environment  tends  to 
discourage. 
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Hardware  and  Operating  System  Requirements 

The  CIC  simulation  may  be  run  on  two  platforms: 

1.  PC  486  with  at  least  16  MB  RAM  (20  or  32  MB  is  better)  running  SCO  Unix  or  Linux, 
Version  1.2.x  or  later. 

2.  Sun  SPARCstation 

The  screen  resolution  should  be  set  to  1024  x  768. 


Downloading  Software 

The  CIC  system  is  summarized  on  the  CIC  Web  page: 

http://www.fcs.net/dtowne/default.htm 

To  download  the  CIC  software,  go  to  htlp://www.fcs.net/dtowne/dnload,  click  on  Cicv2x7.z, 
download  the  file,  and  then  unCompress  it 

CIC  is  a  RIDES  application.  Users  should  install  RIDES  version  4.2.7  or  later.  To  download 
this,  go  to  the  CIC  Web  page,  go  to  the  Download  files  section,  click  on  “The  RIDES  run-time 
simulation  engine  (sRIDES)”,  select  the  desired  platform,  download  the  file,  and  then  gunzip 
it. 


Distribution  Files  and  Installation 


Files 


The  files  may  be  distributed  via  floppy  diskettes  or  via  the  Internet.  Some  of  the  files  will  be 
distributed  compressed  (with  a  .Z  suffix),  and  must  be  uncompressed  prior  to  use.  If  the  files 
are  accessed  from  the  Internet,  some  of  the  file  names  will  differ  slightly.  In  this  case,  those 
names  in  bold  must  be  named  as  shown  below  (the  platform-specific  files  may  be  renamed 
rides  or  RIDES  if  desired.) 


Platform-specific  simulation  engine: 

sridessn.z  for  use  on  a  Sun  SPARCstation  (2  diskettes) 

sridespc.z  for  use  on  an  IBM  compatible  PC  (2  diskettes) 


Platform-independent 

cicvaxb 

CICDescriptions 

SessionPlan 

configl,  config2, .. 

portNames 

rides.defaults 

testml 


files:  (1  diskette) 

(the  CIC  application;  a  and  b  reflect  the  latest  version  number) 
(editable  descriptions  of  various  aircraft  and  ships) 

(an  example  instructional  plan  presented  in  a  session) 

(some  predefined  example  configurations) 

(an  example  list  of  airport  names) 

(specifications  required  by  the  RIDES  system) 

(test  program  used  to  verify  machine  learning  communications) 


CICDescriptions,  SessionPlan,  and  portNames  are  fully  editable  by  the  end  user  using  a  text 
editor.  The  config  files  (see  Appendix  D)  are  modifiable  using  the  CIC  configuration 
authoring  features. 


2 


Installation  Steps 


1.  Copy  the  file  sridespc.z  or  sridessn  to  your  home  directory,  as  follows: 

a.  Put  diskette  #1  into  the  floppy  drive. 

b.  Enter  tar  xvfm  /dev/fdO 

c.  If  the  system  does  not  prompt  you  to  insert  floppy  disk  #2,  you  must  rename  the  file; 
use  a  name  like  tempi.  Then  repeat  step  b  for  floppy  #2,  renaming  the  file  temp2. 
Finally,  concatenate  the  temp  files  with  cat  tempi  temp2  >  temp.Z 

2.  Uncompress  the  .z  file,  and  rename  it  RIDES  or  rides. 

3.  Copy  the  files  from  the  CIC  diskette  to  the  same  directory,  as  in  step  1.  The  files  may  then 
be  moved  to  another  directory,  except  for  rides_defaults  which  should  remain  in  the  home 
directory.  If  necessary,  rename  the  files  marked  above. 

4.  The  simulation  functions  more  smoothly  if  you  place  this  line  in  the  file  .Xdefaults,  found  in 
your  home  directory:  Mwm*resizeBorderWidth:  6 

Check  to  see  if  there  is  already  a  resizeBorderWidth  line  in  the  file;  if  so,  make  sure  the 
integer  given  is  6.  Otherwise,  add  this  line  to  the  file,  exactly  as  shown  (use  tab  or  blanks 
between  the  colon  and  the  6). 


System  Startup 

To  start  the  simulation,  change  to  the  directory  containing  the  CIC  files,  then  enter  the 
statement 

sRides  -s  CICV2.7 

which  assumes  that  the  RIDES  file  is  named  sRides  and  that  the  CIC  file  is  named 
CICV2.7  (spaces  between  arguments  have  been  enlarged  for  clarity). 

(Sun  users  only:  Some  older  Sun  workstations  have  a  bug  in  X.  Try  using  openwin  to  start 
X  on  the  Sun,  rather  than  using  startx.) 

Wait  about  30  seconds,  until  the  mouse  icon  changes  from  a  watch  to  a  hand.  You  will 
now  see  a  start-up  screen  with  a  User  Name  field.  The  name  entered  here  determines  in 
which  of  three  possible  modes  the  simulation  is  run: 

1.  data  collection  mode 

To  identify  a  human  participant  in  a  learning  experiment,  key  in  any  identification  name 
that  is  also  a  legal  file  name  in  your  system  (click  on  the  field,  key  in  the  name,  press  the 
Return  key).  The  name  may  be  the  participant’s  name,  or  it  could  be  an  alphanumeric  code. 
Then  click  on  the  Proceed  button.  Thereafter,  the  keyboard  is  not  used  unless  the  user  has 
been  given  access  to  certain  special  options.  The  screen  will  then  display  the  simulated 
radar  presentation,  various  buttons  used  to  operate  the  simulated  system,  and  a  prompt  to 
click  on  Begin  to  start  the  first  problem.  To  begin  a  problem,  click  on  Begin.  The  system 
will  then  present  problems  in  the  order  specified  in  the  file  SessionPlan,  described  below. 

At  the  end  of  each  problem,  a  message  will  be  displayed  advising  the  user  that  the  problem 
has  ended,  and  to  click  on  Begin  to  start  the  next  problem.  Optionally,  a  performance  score 
will  be  displayed,  and  the  user  may  be  allowed  to  examine  the  true  identities  and  intentions 
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of  all  the  craft  involved  in  the  just-completed  exercise.  At  the  end  of  the  final  exercise,  the 
user  is  advised  that  the  session  is  complete. 

2.  authoring  mode 

To  author  new  tactical  exercises  (configurations)  or  modify  existing  scenarios,  key  in  the 
term  author  to  the  name  ID  field  (click  on  the  field,  key  in  author,  press  the  Return  key). 
Then  click  on  the  Proceed  button.  As  author,  you  may  define  and  save  scenario 
configurations  and  environmental  conditions,  retrieve  and  modify  previously  defined 
configurations,  and  run  problems.  The  file  SessionPlan,  described  below,  does  not  control 
the  session  in  authoring  mode,  and  it  is  not  referenced  by  the  system.  Author  actions  in 
working  trial  problems  are  written  to  the  single  file  named  author .  This  file  contains  data 
just  for  the  previous  problem  worked.  Refer  to  the  section  entitled  Authoring  Mode  for 
further  authoring  details. 

3.  machine  learning  mode 

To  run  problems  to  be  worked  by  a  machine  learning  model,  key  in  machine  to  the  name 
ID  field  (click  on  the  field,  key  in  machine,  press  the  Return  key)  then  click  on  Proceed. 
Now,  the  system  will  automatically  run  the  problems  specified  in  the  SessionPlan  file, 
described  below. 

Quitting  the  Simulation 

To  exit  the  simulation  normally,  click  on  the  Quit  button  displayed  in  the  upper  left  hand 
comer  of  the  screen.  To  abort  a  mn  under  unexpected  conditions,  bring  the  Term  window 
to  the  front  and  press  the  Delete  key. 

The  three  mode  types  are  now  detailed  in  the  following  main  sections. 


Data  Collection  Mode 


If  any  name  other  than  author  or  machine  is  entered  as  the  user  identification,  the 
simulation  runs  in  a  data  collection  mode.  In  this  mode,  the  system  presents  problems 
according  to  the  specifications  in  the  SessionPlan  file,  and  it  writes  out  performance 
data  to  files  named  <usemame>.x  where  username  is  the  user’s  identification,  and  x  is 
an  integer  signifying  the  problem  number,  e.g.,  smith.  1,  smith.2,  smith.  3.  The  format 
of  the  SessionPlan  file  is  provided  in  the  Authoring  section.  The  contents  of  the  user’s 
performance  data  file  is  provided  in  a  subsequent  section  (Task  Performance  Data). 

The  Simulation 

In  data  collection  sessions,  the  simulation  screen  appears  as  shown  in  Figure  1.  The 
major  components  on  this  screen  are  these: 

Utility  buttons,  to  Begin  and  Pause  problems. 

The  radar  display  representing  the  radar  screen,  showing  various  targets  and, 
depending  upon  the  radar  range  selected,  portions  of  the  surrounding  land  mass. 

Display  controls,  used  to  show  or  hide  various  elements  of  the  radar  graphics. 

Range  controls,  used  to  set  the  range  of  the  simulated  radar  system. 

The  Character  Read  Out  box,  which  displays  information  about  the  selected  target. 

Threat  Assessment  buttons  (Friendly,  Hostile,  Unknown),  used  to  classify  the  selected 
target  according  to  its  believed  threat 

User  action  buttons,  used  to  issue  orders  to  other  virtual  crew  members,  or  inquiries 
and  warnings  to  aircraft  and  ships. 

Elapsed  time  and  Local  time  indicators  which  display  the  elapsed  time  on  the  current 
exercise,  and  the  simulated  time  of  day  on  a  24— hour  clock.  Experimental  participants 
should  be  advised  that  the  simulated  time  of  day  may  be  quite  different  than  the  true 
time  of  day  at  their  location,  thus  visual  identifications  may  be  affected  by  the  available 
sunlight. 

User  Prompt  Box,  which  provides  directions  to  the  user,  such  as  “Click  on  Begin  to 
start  your  first  problem.”  This  box  is  also  used  to  prompt  the  author  during  authoring. 

Verbal  communication  display,  the  rectangle  below  the  radar  display,  in  which  all 
verbal  communications  are  displayed.  This  box  displays  the  verbal  commands  that  go 
out  as  a  result  of  selecting  a  user  action  button,  as  well  as  any  responses  from  the  crew 
or  from  contacted  ships  or  aircraft. 

Problem  number,  a  number  that  increases  from  1  to  the  number  of  problems  taken. 

Also  shown  at  the  end  of  each  problem,  if  requested  by  the  experimenter,  a 
performance  score  and  a  target  debriefing  box.  The  target  debriefing  box  appears  over 
the  verbal  communication  box,  and  displays  the  characteristics  of  any  selected  target. 
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Problem:  1 

CONDITIONS t 

C«ilingt  100000  fMt 

Vifllbility  20  mll«s 

Ship's  transmitter t  operational 

Ship's  receiver t  operational 


Unidentified  aircraft  on  a  course  of  319  degrees, 
speed  240  knots,  altitude  12000  feet, 

position  30  degrees,  11  minutes  N;  49  degrees,  38  minutes  X« 
This  Is  US  Navy  Warship. 

Request  you  Identify  yourself  and  state  your  Intentions,  over. 


Figure  1.  The  CIC  Simulation  Screen. 
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User  Actions 


All  user  actions  are  made  via  the  left  mouse  button,  as  follows: 

Begin.  The  user  clicks  on  this  button  to  begin  a  problem.  In  response,  the  system  sets  up 
the  next  exercise  and  starts  the  clock. 


Pause.  If  visible,  this  button  is  used  to  temporarily  pause  a  problem  (stop  the  clock).  If  a 
problem  is  paused,  this  button’s  label  changes  to  Resume.  In  pause  mode,  the  user  may 
select  targets,  view  their  characteristics  in  the  Character  Read  Out  box  (see  below),  change 
the  displayed  radar  range,  or  change  any  of  the  Display  options.  The  system  can  be  set  up 
so  that  users  cannot  pause,  in  which  case  this  button  is  not  visible. 


Display.  Clicking  on  any  of  the  five  check  boxes  toggles  the  visibility  of  the  listed  display 
element.  The  five  boxes  are  independent  of  one  another.  At  the  start  of  each  problem,  the 
Display  buttons  are  initialized  as  follows: 

Commercial  air  routes  unchecked  (not  visible) 

Commercial  air  schedules  unchecked  (not  visible) 

Velocity  leaders  checked  (visible) 

Missile  ship  circle  unchecked  (not  visible) 

Track  numbers  checked  (visible) 


Range.  Clicking  on  any  of  the  five  radio  buttons  sets  the  outer  circle  of  the  radar  display  to 
the  range  selected,  in  miles. 


Target  Selections.  The  user  selects  a  particular  target  displayed  in  the  radar  area  by  clicking 
on  it.  In  response  to  this  an  audible  beep  sounds,  a  red  circle  is  displayed  around  the 
selected  target,  and  the  target’s  characteristics  are  displayed  in  the  table  displayed  to  the 
left  of  the  radar  display.  This  box,  called  the  Character  Read  Out  (CRO)  provides 
information  about  the  target  such  as  its  track  number,  bearing,  heading,  speed,  etc.  The 
values  in  this  table  change  over  time  as  the  selected  target  moves. 


Each  target  sensed  by  the  (simulated)  radar  is  displayed  according  to  its  type  (aircraft, 
surface  vessel,  submarine),  and  its  threat  assessment  (fiiendly,  hostile,  unknown).  Thus 
there  are  9  possible  symbols  for  targets,  as  follows: 


Threat  Assessment 

Unknown 

Friendly 

Hostile 

Air 

/r\ 

/\ 

Surface 

□ 

O 

O 

Sub-surface 

I_lJ 

\/ 

The  threat  assessment  of  a  target  is  initially  established  in  a  problem’s  configuration;  this 
represents  the  initial  determination  that  has  been  assigned  each  target  by  the  CIC  crew 
using  the  AEGIS  system.  These  initial  designations  may  be  correct  (all  friendly  and  hostile 
designations  are  correct),  vague  (many  unknown  designations),  or  incorrect  (one  or  more 
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targets  incorrectly  designated  as  friendly  or  hostile).  The  threat  designation  of  any  target 
may  be  changed  thereafter  by  the  user  to  maintain  a  visual  cue  of  his  or  her  beliefs. 

In  addition,  a  target  has  a  track  number  designation,  a  4-digit  number  assigned  to  the 
target  for  that  exercise,  and  a  velocity  leader,  a  line  whose  direction  indicates  the  current 
heading  of  the  target  and  whose  length  designates  the  current  speed  of  the  target.  As  with 
the  actual  AEGIS  system,  the  relation  between  the  length  of  the  velocity  leader  and  the 
target’s  speed  is  nonlinear,  so  that  small  velocities  can  be  seen,  and  large  velocities  do  not 
overwhelm  the  display.  The  track  number  and  velocity  leader  can  be  made  visible  or 
invisible  by  the  user.  The  following  display  is  a  fiiendly  ship,  designated  as  track  number 
1073,  traveling  in  a  south-easterly  direction. 


The  simulation  comes  stocked  with  four  kinds  of  targets  (see  Appendix  A): 

1.  aircraft 

2.  surface  vessels 

3.  subsurface  vessels 

4.  clutter  (distracting  radar  images  that  appear  to  be  real) 

(Clutter  targets  appear  as  friendly  air  targets,  with  0  speed  and  0  altitude) 

A  particular  exercise  may  involve  any  subset  of  the  available  targets,  each  target 
configured  per  the  requirements  of  the  experimenter. 


All  user  actions  listed  below  pertain  to  the  selected  target.  All  user  actions  that  are  orders 
to  other  crew  members  will  produce  textual  orders  in  the  verbal  communication  box,  after 
some  delay.  After  an  additional  delay,  some  of  the  commands  may  produce  responses  from 
contacted  targets  or  land-based  towers.  See  appendix  B  for  the  built-in  delays  that  pertain 
to  the  user  actions. _ _ _ _ _ 


Friendly.  Unknown.  Hostile.  The  user  clicks  on  these  buttons  to  designate  the  threat  of  the 
currently  hooked  target  as  being  friendly,  unknown,  or  hostile.  In  response,  the  system 
changes  the  graphic  symbol  representing  the  selected  target  to  correspond  to  the  current 
threat  assessment. 

Clear  Target  Display.  The  user  clicks  on  this  button  to  make  the  selected  target  disappear. 
This  can  be  done  to  eliminate  distracting  clutter  targets. 

Restore  Target.  The  user  clicks  on  this  button  to  make  previously  cleared  targets  reappear. 
Each  click  of  this  button  restores  the  display  of  a  previously-cleared  target,  working  from 
the  most  recently  cleared  to  the  first  cleared  target,  for  that  problem. 

Contact  Tower.  The  user  clicks  on  this  button  to  get  in  touch  with  a  land-based  control 
tower  to  determine  if  the  hooked  target  might  be  a  commercial  airliner.  The  particular 
tower  contacted  is  not  explicitly  identified:  it  is  assumed  that  the  appropriate  tower  is 
contacted.  When  the  Contact  Tower  button  is  pressed,  a  verbal  inquiry  is  sent  to 
determine  if  the  hooked  target  might  be  a  commercial  airliner,  under  control  of  the  tower. 
If  there  is  a  commercial  air  liner  in  the  vicinity  of  the  hooked  target  (position  within  5 
miles  of  the  hooked  target  and  altitude  within  5,000  of  hooked  target),  a  response  will  be 
received  to  that  effect,  after  some  delay. 
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Otherwise,  the  tower  will  respond  that  there  is  not  a  commercial  airliner  in  the  vicinity 
indicated  by  the  hooked  target.  Thus,  if  there  are  two  or  more  aircraft  flying  in  a  close 
group,  one  of  which  is  a  commercial  airliner,  the  tower  will  confirm  presence  of  an  airliner 
in  the  area  of  the  hooked  target,  even  if  the  hooked  target  does  not  happen  to  be  the  airliner 
itself. 

Request  Visual  ID.  The  user  clicks  on  this  to  command  the  bridge  to  attempt  to  make  a 
visual  identification  of  the  selected  target  The  bridge  will  respond  with  an  identification, 
after  some  delay,  if  the  following  conditions  are  all  true: 

The  local  time  is  between  6  A.M.  and  6  P.M.  (i.e.,  it  is  daylight). 

The  target’s  altitude  is  less  than  the  ceiling  for  the  problem. 

The  target’s  range  is  less  than  50  miles  and  less  than  the  visibility  for  the  problem. 

Tlliiminate  Target  The  user  clicks  on  this  to  ‘illuminate’  the  selected  target.  This  action 
alerts  the  selected  target  that  it  is  being  acquired  for  defensive  action,  and  also  serves  as  a 
drastic  warning  to  a  target  that  is  not  responding  to  radio  warnings.  After  some  delay,  an 
illuminated  target  will  turn  away  fi'om  the  ship  if  1)  it  is  configured  as  one  which  will  heed 
warnings,  2)  it  is  within  30  miles  range,  and  3)  it  is  an  aircraft  whose  IFF  mode  is  1,2,  or  4. 

Fire  Warning  Shots.  The  user  clicks  on  this  to  fire  warning  shots  at  the  selected  target.  The 
target  will  turn  away  from  the  ship  if  1)  the  target  is  configured  as  one  which  will  heed 
warnings,  and  2)  the  target  range  is  less  than  5  miles. 

Defend  Ship.  The  user  clicks  on  this  to  command  the  crew  to  take  defensive  action  against 
the  selected  target.  There  is  not  a  simulation  of  the  weapons  hitting  or  missing  the  target, 
but  if  the  target  is  within  the  missile  ship  circle  (12  miles)  it  will  disappear  from  the 
screen'. 

Warning.  The  user  clicks  on  any  of  these  six  buttons  to  issue  a  radio  warning  to  the 
selected  target.  Warnings  are  at  three  possible  levels,  and  may  be  issued  on  two  possible 
radio  bands:  (1)  Military  Air  Distress  (MAD),  and  (2)  International  Air  Distress  (lAD). 

The  selected  target  will  receive  the  warning  if  the  following  are  all  true: 
o  the  ship’s  transmitter  is  operational  (if  limited  range,  target  must  be  within  10  miles); 
o  the  target  is  monitoring  the  band  upon  which  the  warning  was  sent  (MAD  or  lAD); 
o  the  target’s  receiver  is  operational. 

The  target  will  turn  away  from  the  ship,  after  some  delay,  if:  1)  the  target  receives  the 
warning,  2)  the  warning  is  issued  at  level  2  or  3,  and  3)  the  target  is  configured  as  one 
which  heeds  warnings.  The  target’s  verbal  response  to  the  warning  will  be  displayed  in  the 
verbal  communication  box  if:  1)  the  target  receives  the  warning,  2)  the  target’s  transmitter 
is  operational,  and  3)  the  ship’s  receiver  is  operational.  If  desired,  the  experimenter  may  set 
the  target’s  verbal  response  to  be  silence  by  creating  a  line  in  CICDescriptions  that 
contains  “  “,  and  setting  the  target’s  selfID  to  that  line  number. 

Pop-up  Targets 

Aircraft  below  2(X)  feet  altitude  are  not  displayed.  This  adds  realism  to  the  exercises,  and  it 
provides  the  author  the  capability  to  produce  targets  that  ‘pop-up’  during  an  exercise,  i.e., 
they  are  not  seen  until  they  rise  above  200  feet. 


'  This  feature  was  introduced  in  Version  2.6. 
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Task  Performance  Data 

The  details  of  each  exercise  run  in  data  collection  mode  are  written  chronologically  to  an 
ASCn  format  data  file.  The  file  created  for  the  first  exercise  run  by  user  Smith  is  named 
Smith.  1,  the  second  is  Smith.2,  etc.  To  minimize  the  data  loss  if  a  power  outage  or 
other  failure  should  occur,  each  exercise  is  written  to  a  separate  data  file.  The  data  file 
contains: 

•  problem  specs  —  user  ID,  problem  number,  time  and  date  of  probleni  presentation, 

scenario  name,  environmental  conditions,  list  of  active  target  types, 
file-  write  interval,  and  number  of  active  targets  and  clutter  targets. 

•  periodic  updates  —  the  positions,  speeds,  etc.  of  each  target  at  each  update  time; 

•  user  actions  —  overt  actions  made  by  the  user; 

•  replies  —  radio  messages  received  from  targets,  towers,  and  other  crew  members; 

•  end  marker  —  a  record  coded  99,  followed  by 

a.  seconds  since  start  of  problem; 

b.  the  user’s  performance  score; 

c.  eleven  measures  of  performance,  corresponding  to  the  weights  W2  through  W12 
detailed  in  the  section  entitled  Scoring  the  User’s  Performance. 

Problem  Specs 

Each  exercise  file  is  headed  with  sufficient  information  to  completely  replay  the 
problem  (given  that  the  scenario  file  originally  used  is  still  available).  This  header 
information  provides  the  following: 

1.  title:  The  name  of  this  data  file 

2.  date  and  time  of  file  creation  (time  may  be  in  error  on  some  installations) 

3.  scenario  name  Name  of  scenario  configuration  file 

4.  environment  data  (16  characters,  total) 

ceihngButtons  (3):  001,005,010,025,  or  100  (thousand  feet) 

visibUityButtons  (3) :  01 ,05 , 1 0,20,30  (miles) 

recvrButtons  (2):  0,1, 2,3  (failed,  OK,  intermittent,  limited  range) 

xmtrButtons  (2):  0,1, 2,3  (failed,  OK,  intermittent,  limited  range) 

local  time  (6):  like  “18:30” 

5.  file  write  interval,  in  seconds 

6.  number  of  active  targets  (2  chars),  number  of  active  clutter  targets  (2  chars). 

Problem  Data 

Problem  data  are  written  to  the  file  as  the  problem  progresses.  Data  are  of  three  types: 

(1)  periodic  updates  which  reflect  the  status  of  each  target  at  a  particular  time; 

(2)  user  actions,  written  whenever  the  user  makes  an  overt  action,  and 

(3)  replies,  written  whenever  a  reply  is  received  to  some  command  or  inquiry. 

Each  record  starts  with  a  2-digit  code  as  listed  in  the  table  below.  Following  each  code 
is  the  time  at  which  the  action  took  place,  in  seconds,  after  start  of  problem.  For  all 
record  types  except  periodic  update,  this  is  followed  with  the  track  number  of  the  target 
involved. 
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code 

activity 

01 

periodic  target  update 

02 

hook  (select)  a  target 

03 

warn  the  hooked  target 

04 

the  warned  target  replies 

05 

fire  warning  shots  near  the  hooked  target 

06 

illuminate  the  hooked  target 

07 

request  visual  ID  of  the  hooked  target 

08 

receive  visual  ID  of  hooked  target  from  bridge 

09 

contact  the  tower  regarding  the  hooked  target 

10 

receive  information  from  tower  regarding  hooked  target 

11 

change  threat  assessment  of  hooked  target 

12 

open 

13 

open 

14 

clear  hooked  target  display  from  screen 

15 

restore  last  cleared  target 

16- 

29 

—  open  — 

30 

change  display  (commT  air  routes, ...,  radar  range) 

31-49 

—  open  — 

50 

a  hostile  target  fires  at  own-ship 

60 

own-ship  fires  at  hooked  target 

99 

end  of  problem,  plus  user’s  performance  score 

Codes  for  Performance  Data  Files 

For  example,  a  record  05  0083  1244  states  that  the  user  fired  warning  shots  near 
target  1244,  83  seconds  into  the  problem. 

Periodic  Updates  (code  01) 

Periodic  updates  are  signified  by  a  record  coded  01,  followed  by  the  time  at  which  the 
update  applies.  This  record  is  followed  by  a  number  of  sub-records,  each  of  which 
describes  tihe  condition  of  one  active  target,  at  that  time. 

The  periodic  updates  provide  all  pertinent  information  about  the  situation  at  a  particular 
instant.  A  periodic  update  is  automatically  written  when  the  problem  starts.  This  initial 
update  provides  data  about  all  the  active  targets,  including  any  clutter.  Thereafter,  a 
periodic  update  is  written  each  S  seconds,  where  S  can  be  set  by  the  experimenter. 
These  subsequent  updates  do  not  list  the  clutter  targets  again,  as  they  never  change 
position.  A  final  update  is  written  to  reflect  terminating  conditions. 

At  each  update  time,  a  record  is  written /or  each  active  target  expressing; 
track  number 

bearing  from  own  ship,  in  degrees 
range  from  own  ship,  in  miles 
altitude,  in  feet 
speed,  in  knots 
heading,  in  degrees 

current  threat  assessment  (u,  f,  or  h  for  unknown,  friendly,  or  hostile  respectively) 
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Example  Periodic  Update 


01  30  (this  periodic  update  describes  the  problem  status  after  30  seconds) 

1024  045  044  001000  0445  124  u  (the  first  active  target) 

1144  150  018  024500  0266  090  h 
1010  018  009  000000  0012  242  f 

1211  268  029  021432  0388  074  f 

1095  111  006  000000  0022  167  u  (the  5th  active  target) 

User  Actions  (codes  02,  03,  05,  06,  07,  09,  11,  14,  15,  and  60) 


Each  user  action  is  recorded  with  a  code  that  indicates  what  the  action  was,  the  time  at 
which  the  action  was  performed,  and  the  target  involved  (always  the  currently  hooked 
target).  In  addition,  a  few  of  the  action  types  produce  an  additional  character  to  further 
describe  the  situation. 


Honk  target  (code  021.  This  record  type  ends  with  a  2-digit  number  that  is  used  by  the 
Replay  function  within  the  simulation  system: 

02  12  1024  04  (hook  target  1024, 12  seconds  into  the  problem) 

Warn  hooked  target  (code  031.  This  record  type  reflects  the  level  at  which  the  warning 
was  issued  and  the  radio  band  on  which  the  warning  was  issued — (1)  military  or  (2) 
international  air  distress: 

03  29  1024  21  (warn  target  1024,  29  seconds  into  the  problem,  a  level  2 

warning  (2),  on  Military  Air  Distress  (1). 

Fire  warning  shots  (code  05). 

05  34  1024  (fire  warning  shots  near  target  1024,  34  seconds  into  the 

problem.) 

Illuminate  hooked  target  (code  06). 

06  50  1024  (illuminate  target  1024,  50  seconds  into  the  problem.) 

Request  visual  ID  of  hooked  target  (code  071. 

07  55  1024  (request  visual  ID  of  target  1024,  55  seconds  into  the  problem.) 

Contact  tower  regarding  hooked  target  (code  09). 

09  60  1024  (contact  tower  regarding  target  1024,  60  seconds  into  the 

problem.) 

Change  threat  assessment  of  hooked  target  (code  11). 

11  65  1024  friendly  (change  assessment  of  target  1024  to  friendly) 

(other  codes  are  “hostile”  and  “unknown”) 


Clear  hooked  target  from  display  (code  14). 

14  75  1024  (clear  target  1024  from  screen,  at  75  seconds.) 

Restore  hooked  target  on  screen  (code  15). 

15  85  1024  (restore  display  of  target  1024,  at  85  seconds.) 

Fire  at  hooked  target  (code  60). 

60  95  1024  (fire  at  target  1 024,  at  95  seconds.) 
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Replies  and  Target  Actions  (codes  04,  08,  10,  50) 

The  remaining  codes  refer  to  actions  by  other  crew  members  and  by  targets. 

The  warned  target  replies  (code  04) 

04  69  1024  (target  1024  identifies  itself  in  response  to  warning,  at  69 

seconds)  This  record  is  not  written  if  the  user  does  not  receive  a  verbal  response  from 
the  warned  target  (because  of  equipment  malfunctions).  The  nature  of  the  self 
identification  is  whatever  the  experimenter  established  for  the  warned  target. 

The  bridge  responds  with  a  visual  ID  attempt  (code  08) 

08  77  1024  y  (the  bridge  responds  with  visual  ID  of  target  1024  at  77  seconds) 

The  code  ‘y’  signifies  that  the  bridge  was  able  to  make  some  find  of  identification  of 
,  the  target,  the  nature  of  which  is  whatever  the  experimenter  established  for  that  target. 
Alternatively,  the  code  ‘n’  signifies  that  the  bridge  was  not  able  to  make  an 
identification  due  to  excess  range,  poor  light,  or  atmospheric  conditions  (or  the  target 
was  clutter). 

The  tower  responds  (code  10) 

10  87  1024  y  (the  tower  responds  concerning  target  1024  at  87  seconds) 

The  code  ‘y’  signifies  that  the  tower  verifies  that  the  tower  is  controlling  a  commercial 
airliner  in  the  vicinity  of  (within  5  miles)  the  hooked  target  and  within  5,000  feet  of  its 
altitude.  Alternatively  the  code  ‘n’  signifies  that  the  tower  denies  that  it  has  control  of  an 
airliner  in  the  position  and  altitude  indicated  by  the  user. 

A  target  fires  on  own  ship  (code  501 

50  97  1024  (target  1024  fires  on  own  ship  at  97  seconds) 

Changes  to  the  Simulation  Display  (code  30) 

Code  30  signifies  that  the  user  changed  some  element  of  the  simulation  Display.  For 
consistency  and  ease  of  data  analysis,  this  record  type  is  in  the  same  format  as  all  other 
data  records,  although  the  track  number  of  the  hooked  target  has  no  real  bearing  on  this 
record  type.  Following  the  hooked  target  track  number  is  one  blank  and  then  digits  that 
indicate  which  type  of  display  element  was  changed,  and  its  new  value. 

The  characters  following  the  hooked  target  track  number  are  these: 

1  changed  visibility  of  commercial  airline  routes 

2  changed  visibility  of  commercial  airline  schedule 

3  changed  visibility  of  velocity  leaders 

4  changed  visibility  of  missile  ship  circle 

5  changed  visibility  of  track  numbers 

6  changed  radar  range 

Following  the  digits  1  through  5  is  a  blank  and  then  ‘v’  or  ‘i’  to  indicate  that  the  display 
element  is  visible  or  invisible.  Following  digit  6  is  a  blank  and  the  new  radar  range,  as 
a  3-character  number. 


Examples 
30  107 

1024 

1 

V 

30 

147 

1024 

2 

i 

30 

153 

1024 

6 

016 

(user  sets  commercial  air  routes  to  visible) 
(user  sets  commercial  air  schedule  to  invisible) 
(user  sets  radar  range  to  16  miles) 
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An  output  file  for  an  exercise  might  look  like  the  following: 


P28.7 

Thu  Sep  8  00:08:48  1994 
Of fCourseAirLiner 
001  30  1  1  12:30 


10 

4  1 

1024 

045 

044 

001000 

0445 

124 

1134 

150 

018 

024500 

0266 

090 

1543 

018 

009 

000000 

0012 

242 

1754 

268 

029 

021432 

0388 

074 

7001 

111 

006 

000000 

0000 

000 

02 

8 

1134 

06 

01 

10 

1024 

045 

043 

001050 

0445 

124 

1134 

151 

018 

024800 

0266 

090 

1543 

018 

009 

000000 

0012 

245 

1754 

265 

030 

021432 

0388 

075 

02 

19 

1754 

24 

01 

20 

1024 

045 

043 

001050 

0445 

124 

1134 

151 

018 

024800 

0266 

090 

1543 

018 

009 

000000 

0012 

245 

1754 

265 

030 

021432 

0388 

075 

03 

37 

1754 

21 

04 

69 

1754 

07 

85 

1754 

30 

103 

1024 

6  016 

08 

107 

1754 

y 

99 

480 

120 

7002  etc 

(participant  P28,  problem  number  7) 

(date  and  time  exercise  was  run) 

(name  of  configuration  for  this  exercise) 
(environmental  conditions) 

(file  write  interval,  seconds) 

(number  real  targets,  number  clutter  targets) 
u  (initial  conditions  of  the  5  targets) 
u 
f 
u 

f  (this  clutter  target  will  not  be  listed  again) 

(hook  target  1 134,  8  seconds  into  exercise) 

(periodic  update  at  10  seconds) 

u 

u 

f 

u 

(hook  target  1754  at  19  seconds) 

(periodic  update  at  20  seconds) 

u 

u 

f 

u 

(warn  target  1754) 

(target  1754  replies  to  warning) 


(request  visual  ID  of  target  1754) 

(user  sets  radar  range  to  16  miles) 

(bridge  returns  visual  ID  of  target  1754) 

(end  of  problem  at  480  seeonds;  score  120) 
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Authoring  Mode 

To  author  exercises,  start  the  system  using  the  name  author.  This  allows  certain 
keyboard  commands  to  be  made,  and  it  provides  access  to  a  scenario  configuration 
screen  which  is  unavailable  to  experiment  participants. 

Prior  to  running  an  exercise,  the  author  may  specify  and  save  one  or  more  sets  of  initial 
conditions.  Additionally,  the  author  may  specify  sets  of  scheduled  maneuvers.  These 
are  real-time  changes  in  headings,  speeds,  and  dtitudes  of  various  crafts  that  are  not  a 
result  of  the  user’s  actions. 

Then,  when  the  author  clicks  on  Begin,  the  system; 

1.  restores  the  conditions  of  the  latest  configuration  recalled  by  the  author; 

2.  reads  in  the  latest  scheduled  maneuvers  recalled  by  the  author,  if  any;  and 

3.  starts  the  exercise  running. 

The  author’s  actions  on  each  exercise  are  written  to  the  file  named  author,  with  data  for 
each  problem  replacing  the  prior  data. 

Thus,  an  exercise  can  be  run  multiple  times,  each  time  starting  with  the  same  conditions 
and  each  time  involving  the  same  scheduled  maneuvers.  Alternatively,  the  author  can 
recall  different  conditions,  and  can  modify  and  save  different  problem  conditions.  To 
change  conditions,  follow  the  instructions  below,  then  save  the  revised  configuration. 

Backing  Up  Exercise  Configurations 

Configurations  represent  a  considerable  effort  invested  in  establishing  useful 
experimental  conditions.  Consequently,  they  should  be  backed  up  to  diskette  in  case  of 
hard  disk  failures  or  inadvertent  changes  caused  by  accidentally  saving  to  an  existing 
configuration  name. 

Exercise  Creation  or  Modification 

An  exercise  is  specified  in  terms  of  1)  initial  conditions  and  2)  optional  scheduled 
maneuvers  of  targets.  These  two  sets  of  information  are  independent,  thus  an 
experimental  trial  can  involve  any  selected  initial  scenario  configuration,  and  any 
selected  specification  of  scheduled  maneuvers,  or  none. 

Initial  Conditions 

Initial  conditions  (scenario  configurations)  are  established  by  1)  specifying  the 
characteristics  of  the  various  targets  that  will  be  involved  in  the  scenario,  and  2)  setting 
external  conditions  by  making  selections  on  the  Scenario  Configuration  screen  for  such 
factors  as  weather  and  the  operability  of  the  simulated  communication  equipment  of  the 
user’s  ship.  Target  characteristics  include  such  factors  as  target  positions,  headings, 
speeds,  altitudes,  intentions,  and  equipment  operability. 

Any  unique  set  of  initial  conditions  can  be  saved  in  a  file  named  by  the  author.  The 
configuration  name  is  not  seen  by  the  participant,  thus  it  can  be  descriptive  of  the 
situation,  such  as  terroristAttack,  ojfCourseAirliner,  or  failedReceiver. 
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Setting  Initial  Scenario  Conditions 

The  general  steps  in  defining  initial  scenario  conditions  are  these: 

1.  Press  ‘s’  to  move  to  the  Scenario  Configuration  screen  (Figure  2),  and  enter  the 
name  of  the  configuration  that  is  most  similar  to  the  one  to  be  specified  into  the  Get 
Scenario  box  (click  in  the  box,  key  in  the  file  name,  press  Enter).  See  Appendix  D  for 
the  names  of  the  configurations  supplied  with  the  system. 


Scenario  Configuration 


Airport  Maineo 


Save  Airport  Names:  NO 


Data  File  Write  interval: 


Seconds 


Save  as  Scenario; 


Get  Scenario: 


Get  Flight  Plan: 


Figure  2.  The  Scenario  Configuration  Screen 
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Press  ‘s’  again  to  return  to  the  simulation  screen.  All  the  visible  (active)  targets  for  the 
retrieved  configuration  are  seen  in  their  initial  positions  on  the  radar  screen.  The 
remaining  {inactive)  targets  are  initially  invisible. 

2.  To  bring  a  new  target  into  the  simulation,  first  make  the  inactive  targets  visible  by 
pressing  the  ‘v’  key.  Now  four  ‘stacks’  of  targets  will  be  seen  below  the  radar 
circle,  one  stack  for  each  type  of  target  (air,  surface,  subsurface,  clutter). 

To  bring  in  a  new  target: 

a.  click  on  the  stack  holding  the  target  type  desired.  This  will  select  the  top  target  of 

that  type. 

b.  hold  down  the  ‘m’  key  (for  move)  and  click  on  the  radar  screen  where  the 

selected  target  should  be  positioned.  The  selected  target  will  move  to  that 
position.  Further  refinements  in  position  can  be  made  at  any  time  by  selecting  a 
target  then  clicking  at  its  new  position  with  the  ‘m’  key  depressed. 

To  ‘remove’  a  target  from  a  scenario,  move  it  from  the  radar  screen  back  to  its  stack 
(again,  click  on  the  target,  then  click  on  its  stack  while  holding  down  the  ‘m’  key). 

3.  For  each  active  real  target  (i.e.,  not  clutter),  set  its  speed,  altitude  (if  air),  and 
heading  by  doing  the  following: 

a.  press  the  f  key  (for  fly-by-wire),  and  observe  the  following  control  box: 


b.  Slide  the  Time  control  to  zero  (this  is  very  important). 

c.  Select  a  target  by  clicking  on  it  (clutter  targets  cannot  be  configured). 

d.  Operate  the  three  controls  to  establish  the  target’s  speed,  heading,  and  altitude, 
llie  target  will  respond  instantly  to  these  controls. 

e.  Repeat  steps  c  and  d  for  all  non-clutter  targets. 

When  all  targets  have  been  set  up,  press  the  f  key  to  make  the  ‘fly-by-wire’  controls 
disappear. 

4.  Specify  the  behaviors  and  characteristics  of  the  active  targets  by  doing  the  following: 

a.  Press  the  c  key  (for  configure  target). 

b.  Select  a  target  by  clicking  on  it. 

c.  Make  selections  and  entries  in  the  target  configuration  box,  as  detailed  below. 

d.  Repeat  steps  b  and  c  for  all  targets. 
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When  all  targets  have  been  defined,  press  the  c  key  to  dismiss  the  configuration  box. 

5.  When  the  initial  target  conditions  are  as  desired,  move  to  the  Scenario  Configuration 
screen  by  pressing  the  s  key.  Set  the  Atmospheric  Conditions,  Own  Ship  Readiness, 
Local  Time,  Termination  Conditions,  Data  File  Write  Interval,  and  airport  names 
(optional)  as  detailed  below. 

6.  Save  the  scenario  configuration  by  entering  a  name  to  the  Save  as  Scenario  box. 
(click  on  the  scenario  name  box,  key  in  a  legal  file  name,  press  Enter).  When  the 
Enter  key  is  pressed,  the  target  characteristics  set  in  steps  2  through  4  and  the 
external  conditions  set  in  step  5  are  written  to  the  file  you  have  specified  as  the 
scenario  configuration  name. 

7.  Run  the  exercise  by  returning  to  the  simulation  screen  (press  s)  and  clicking  on 

Begin.  The  label  of  the  Begin  button  changes  to  Stop,  and  the  clock  starts  to  run. 

As  an  author,  you  can  halt  a  problem  by  clicking  on  Stop,  or  pause  a  problem  at  any 
time.  Each  time  an  author  clicks  on  Begin,  the  system  restores  the  latest  configuration 
saved  or  retrieved,  and  starts  the  simulation  running  in  real  time. 


Note:  If  an  author  Gets  a  configuration,  then  makes  some  changes,  then  clicks  on 
Begin,  the  problem  will  run,  starting  at  that  newly  revised  condition.  That  condition  is 
lost,  however,  unless  the  author  saves  the  modified  configuration  prior  to  running  the 
problem. 


The  following  provides  more  detail  on  the  steps  outlined  above. 

Configuring  Individual  Targets 

The  simulation  comes  stocked  with  a  fixed  number  of  surface  vessels,  submarines, 
aircraft,  and  clutter  (see  Appendix  A).  Each  of  these,  generically  called  ‘targets’, 
maintains  its  inherent  type  for  all  time,  i.e.,  an  author  cannot  change  a  ship  into  an 
aircraft.  Each  target  carries  a  unique  ‘t’  number  that  identifies  it.  Only  die  author  can  see 
this  reference  ID,  in  the  Target  Configuration  box,  described  below. 

Authors  can  shape  each  target  within  its  own  class.  For  example,  target  TOl  could  be  a 
helicopter  in  one  scenario,  and  a  jet  fighter  in  another  configuration.  Specifications  for  a 
particular  target  apply  to  the  configuration  in  which  that  target  is  saved,  i.e.,  a  target 
may  be  used  differently  in  different  configurations. 

Clutter  targets  need  not  be  configured  by  the  author;  they  are  preset  to  appear  as 
aircraft-type  symbols  on  the  screen,  but  they  will  not  respond  to  any  commands,  they 
cannot  be  seen  when  a  visual  ID  is  attempted,  nor  will  they  move  about 

To  set  the  characteristics  of  targets  (step  4  above)  press  the  c  key  (for  configure).  The 
following  box  will  appear  (if  a  target  is  already  selected,  its  characteristics  will  display 
in  the  box,  otherwise  the  data  in  the  box  will  be  blank). 

Select  the  target  to  be  specified,  and  observe  its  current  characteristics. 

Boxes  containing  numbers  are  set  by  clicking  in  the  box,  keying  in  a  number,  then 
pressing  Enter.  Boxes  containing  OK  or  yes/no  or  checks  are  set  by  clicking  in  the  box. 


18 


Target:  t02  air 


Self  ID:  1 01 1  small  private  aircraft 
Visual  DDfC^  military  fighter 
Identity:  I  02l  military  fighter 
Will  Fire  lyesl  Will  Heed  Warning [y^ 
IFF  Modern  IFF  Code:  [1025] 
Receiver:  I  OKI  Transmitter: 
Monitoring:  IADKI  MADQ 
Track  I1234 1 


Cancel  OK  | 


Self  ID,  Visual  ID,  and  Identity  all  refer  to  verbal  descriptions  contained  in  the  ASCII 
file  named  CICDescriptions.  These  are  not  used  for  clutter  targets,  thus  it  doesn’t 
matter  what  text  is  displayed  here  for  a  clutter  target.  The  entry  is  the  line  number 
in  this  file  that  contains  the  verbiage  desired.  This  file,  CICDescriptions,  can 
be  edited  and  extended  to  establish  any  verbal  descriptions  desired.  Each  description 
must  be  one  line  in  the  file. 

In  the  example  shown  above,  line  1  of  CICDescriptions  contains  the  phrase 

small  private  aircraft 

while  line  2  contains  the  phrase 

military  fighter 

Self  ID  is  the  response  a  target  returns  to  the  ship  when  asked  to  identify  itself.  If 
desired,  this  could  refer  to  a  record  in  the  CICDescriptions  file  that  contains  “  “,  i.e., 
silence.  The  Self  ID  can  be  truthful  or  devious. 

Visual  ID  is  the  response  given  when  the  bridge  is  successful  in  making  a  visual  ID. 
Generally,  this  is  a  general  description,  such  as  “military  aircraft”  or  “commercial 
vessel”. 

Identity  is  the  true  identification  of  the  target. 

If  a  number  is  entered  for  any  of  the  above  three  which  is  greater  than  the  number  of 
lines  in  the  CICDescriptions  file,  the  text  shown  will  be  **  EOF  **  (End  of  File). 

Will  Fire  specifies  whether  the  target  will  fire  on  the  ship  or  not  (i.e.,  whether  it  is 
hostile).  See  IFF  Mode,  below,  for  the  range  at  which  various  targets  will  attack.  Once 
one  target  has  fired  on  own  ship,  within  a  problem,  no  other  targets  will  fire. 

Generally,  a  target  firing  on  own  ship  should  terminate  a  problem. 
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Will  Heed  Warning  specifies  whether  the  target  will  heed  warnings  that  it  receives. 
A  target  can  be  set  up  as  hostile  (will  fire),  but  to  heed  warnings  if  it  receives  them. 
This  represents  a  target  that  will  attack  if  possible,  but  not  unless  it  thinks  it  is  safe  to 
do  so.  A  hostile  target  that  wiU  not  heed  warnings  will  attack  whether  warned  or  not. 

IFF  Mode  is  a  digit  (0,  1,  2,  3,  or  4)  which  describes  the  target  to  the  simulation 
system.  This  should  be  set  to  0  for  non-military  ships  and  aircraft;  to  1,  2,  or  4  for 
military  ships  and  aircraft;  and  to  3  for  commercial  airliners.  This  digit  is  used  along 
with  the  target  type  (surface,  air  or  subsurface)  to  determine  whether  or  not  it  senses 
being  illuminated,  and  the  range  at  which  it  would  fire  on  the  user’s  ship,  if  it  is  hostile. 

The  simulation  system  uses  IPT  mode  as  follows: 

Only  military  aircraft  (IFF  mode  1, 2,  or  4)  can  sense  being  illuminated. 

Only  commercial  airliners  (IFF  mode  3)  are  recognized  by  the  land-based  tower. 

Hostile  ships  and  aircraft  with  IFF  mode  0  attack  within  2  mile  range. 

Hostile  ships  and  aircraft  with  IFF  mode  1, 2,  or  4  attack  at  10  miles  range. 

Thus,  IFF  mode  0  describes  a  small  non-military  craft  that  could  carry  a  weapon  of 
some  limited  type. 

IFF  Code  is  currently  unused. 

Receiver  and  Transmitter  refer  to  the  operability  of  the  target’s  radio  equipment. 

By  clicking  on  this  field,  for  either  Receiver  or  Transmitter,  the  value  will  cycle  through 
the  following  values: 

OK 

intermittent  (works  half  the  time) 
limited  range  (10  miles  effective  range) 
failed 

Monitoring  specifies  which  radio  bands  are  monitored  by  the  target.  None,  one,  or 
both  boxes  may  be  checked  (checked  means  the  band  is  monitored  by  the  target). 

Track  is  the  track  number  to  use  for  the  target.  This  is  the  4-digit  number  that  will 
appear  on  the  radar  screen  for  that  target  Use  track  numbers  7xxx  for  clutter. 

After  setting  a  target  as  desired,  click  on  another  target  and  set  its  characteristics. 
Continue  to  set  target  characteristics  until  all  are  set  as  desired.  Then  click  on  OK. 


Note  that  these  target  characteristics  set  as  described  above  are  not  saved 
until  the  configuration  is  saved  (on  the  scenario  configuration  screen). 
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Specifying  External  Conditions 

The  author  can  establish  additional  conditions  on  the  Scenario  Configuration  screen 
(Figure  2).  To  make  this  screen  appear  (or  disappear),  press  the  s  key  (for  scenario), 
then  set  the  following  conditions: 

Atmospheric  Conditions 

•  Ceiling  —  the  altitude  above  which  targets  cannot  be  seen,  during  daytime. 

•  Visibility  —  the  distance  beyond  which  targets  cannot  be  seen,  during  daytime. 

Own  Ship  System  Readiness,  the  operability  of  own  ship’s  transmitter  and  receiver. 
Limited  Range  means  transmitter  or  receiver  has  an  effective  range  of  10  miles. 

Local  time  (24-hour  clock)  at  the  start  of  the  problem,  which  affects  ability  to  visibly 
observe  targets,  and  possible  presence  of  commercial  airliners,  per  their  schedules. 

Termination  Conditions 

The  author  can  specify  what  causes  an  exercise  to  terminate.  The  four  variables  that  can 
be  used  to  terminate  exercises  are: 

A.  Elapsed  time,  in  seconds.  Enter  a  large  number  (like  9999)  if  elapsed  time  is  not  to 
be  considered  in  terminating  a  problem. 

B.  Own  ship  fires.  A  check  mark  indicates  that  this  variable  is  part  of  the  termination 
condition. 

C.  Own  ship  fired  upon.  A  check  mark  indicates  that  this  variable  is  part  of  the 

termination  condition. 

D.  Range  of  nearest  threat  Enter  miles,  to  one  decimal  place,  if  this  variable  is  part  of 
the  termination  condition. 

And/Or  selection.  If  more  than  one  of  the  above  four  variables  has  been  set,  select  the 
And  button  or  the  Or  button  to  specify  whether  just  one  or  all  specified  conditions  are 
required  to  terminate  the  problem. 

Example: 

If  elapsed  time  is  set  to  400,  B  is  checked,  C  is  not  checked,  D  is  1,  and  the  OR  button 
is  checked  (terminate  when  A  or  B  or  D  is  true),  the  problem  will  terminate  when 
elapsed  time  reaches  400,  or  when  own  ship  fires,  or  when  the  range  to  the  nearest 
hostile  is  1. 

Data  FUe  Write  Interval. 

The  author  can  specify  how  often  the  target  data  will  be  written  to  file,  thereby  affecting 
the  size  of  the  output  file.  If  a  short  time,  such  as  1  or  2  seconds  is  specified,  the 
system  will  attempt  to  update  the  simulation  and  write  to  file  as  often  as  requested, 
however  the  speed  of  the  host  computer  and  the  number  of  targets  involved  in  the 
scenario  might  prevent  the  system  from  updating  as  rapidly  as  requested.  The  output 
file  indicates  the  time  at  which  the  targets  were  updated,  so  the  author  can  determine  if 
the  system  is  able  to  meet  the  request,  on  a  particular  host  computer. 

Airport  Names 

Airport  names  can  be  specified  in  a  file  named  portNames.  If  this  is  done,  the  names 
entered  there  will  be  used  for  all  exercises  until,  or  unless,  a  scenario  is  run  that 
contains  its  own  names.  To  apply  specific  names  to  a  scenario,  enter  the  desired  names 
on  the  Configuration  screen,  and  then  set  the  Save  Airport  Names:  setting  to  YES  (by 
clicking  on  it),  prior  to  saving. 
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Scheduled  Maneuvers 

Scheduled  maneuvers  are  changes  in  speeds,  headings,  and  altitudes  of  various  targets 
that  are  pre-ordained,  i.e.,  they  are  carried  out  regardless  of  actions  taken  by  the  user 
of  the  simulation.  This  allows  the  developer  of  an  exercise  to  create  a  wide  variety  of 
actions  that  are  not  under  the  control  of  the  CIC  decision-maker. 

Deflning  Scheduled  Maneuvers 

Scheduled  maneuvers  by  ships  and  aircraft  may  be  specified  independently  of  the 
scenario  configuration.  Scheduled  maneuvers  are  changes  in  heading,  speed,  or 
altitude,  over  some  time  period,  of  various  ships  or  aircraft.  Clutter  targets  cannot  be 
maneuvered. 

Each  set  of  defined  maneuvers  is  saved  in  a  file,  so  any  particular  scenario  (set  of  initial 
and  external  conditions)  could  be  run  with  different  maneuvers.  The  author  can  specify 
maneuvers  in  two  alternate  ways: 

1.  by  using  the  fly-by-wire  controls  to  change  headings,  speeds,  and  altitudes  as  a 
scenario  runs;  or 

2.  by  editing  a  text  file  that  specifies  the  maneuvers  of  various  craft 

Since  the  first  of  these  techniques  produces  a  text  file,  the  two  techniques  can  be  used 
in  combination  as  well,  allowing  the  author  to  initially  ‘demonstrate’  maneuvers  with 
the  displayed  controls,  but  make  minor  corrections  directly  in  the  resulting  text  file  if 
desired. 

Specifying  Scheduled  Maneuvers  with  the  Fly-by-Wire  Controls 

To  specify  maneuvers  during  a  problem  do  the  following  in  authoring  mode; 

1.  Set  up  any  initial  conditions  desired,  save  the  configuration  if  desired,  and  click  on 

the  Begin  button. 

2.  When  the  simulation  reaches  a  point  at  which  a  maneuver  is  desired,  click  on  the 

Pause  button. 

3.  Press  the  f  key  to  display  the  fly-by-wire  controls. 

4.  Select  the  target  to  be  maneuvered,  if  it  is  not  already  selected. 

5.  Slide  the  Time  control  to  display  the  time  period  over  which  the  maneuver  is  to  take 
place  (this  must  be  greater  than  0).  A  change  of  heading  that  requires  15 
seconds  would  be  indicated  by  sliding  the  Time  control  to  display  15. 

6.  Slide  the  Heading,  Speed,  or  Altitude  control  to  the  desired  new  value,  and  release 
the  mouse.  If  desired,  change  one  or  more  of  the  three  target  characteristics  (it  is  not 
necessary  to  reset  the  Time  slider  unless  a  second  change  should  take  a  different 
time).  No  visual  response  will  be  seen  in  the  selected  target  at  this 
time,  since  the  problem  is  paused. 

7.  Resume  the  problem  (the  fly-by-wire  box  can  be  left  on-screen,  or  removed  by 
pressing  f  again),  and  note  Aat  the  maneuvered  target  changes  to  the  limit  requested, 
in  the  time  specified. 
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8.  Repeat  steps  3  through  7  to  specify  as  many  maneuvers  as  desired.  There  is  no 
requirement  that  one  target’s  maneuver  be  completed  before  another  is  specified. 

9.  Stop  the  problem. _ 

At  this  point,  all  maneuvers  that  were  specified  via  the 
controls  have  been  written  to  a  data  file  named  flightPlan. _ 

10.  Before  running  another  exercise,  rename  the  flightPlan  file  to  some  other  name  of  your 
choosing  (running  the  simulation  again  will  wipe  out  the  previous  file).  If  desired,  you 
can  make  direct  text  edits  to  the  file  by  referring  to  the  following  section.  This  is  the 
easiest  way  to  modify  an  existing  maneuvering  file. 

11.  Test  the  maneuvers  by  Getting  the  newly  named  flight  plan  on  the  Scenario  Configuration 
screen,  and  running  the  simulation.  The  previously  recorded  maneuvers  will  be  repeated. 

Specifying  Scheduled  Maneuvers  in  a  Text  File 

Any  number  of  text  files  can  be  created  to  specify  scheduled  maneuvers.  The  files  can  be 
copies  of  the  flightPlan  file  created  via  the  fly-by-wire  controls,  as  described  above,  or  they 
can  be  created  from  scratch  using  a  text  editor.  The  format  of  the  file  is  as  follows: 

First  line.  The  first  line  in  the  file  is  not  used,  but  there  must  be  a  first  line  that  contains  some 
text.  A  good  use  of  this  line  is  to  state  what  the  file  describes. 

Data  Lines.  The  remaining  lines  in  the  file,  except  for  the  last  line,  contain  the  maneuvering 
data,  one  line  per  maneuver,  in  the  following  format 


T 

Attribute 

Attribute 

Time 

# 

Value 

Interval 

0016 

01 

h 

00180 

10 

0036 

01 

s 

00060 

05 

0050 

02 

a 

02250 
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Characters  1  through  4:  The  time,  in  seconds,  at  which  the  maneuver  is  to  start. 

Characters  5  through  6;  The  target  number  involved  (the  target’s  T  number). 
Character  7:  Enter  h  for  heading,  s  for  speed,  a  for  altitude  change 

Characters  8-12:  The  ending  value  for  the  heading,  speed,  or  altitude 

Characters  13-14:  The  duration,  in  seconds,  required  to  execute  the  maneuver. 

(enter  01-99  for  duration  less  than  100;  else  enter  C1-C9  for  100-900  seconds)^ 
Last  line.  The  last  line  must  contain  ‘end’. 


Example  Maneuvering  File: 

authored  maneuvers 

001601h0018010 

003601s0006005 

005002a0225020 

end 


Here,  the  first  data  line  says:  Change  the  heading  of  target  01  to  180  over  10  seconds, 
starting  16  seconds  into  the  problem. 


^  The  Cl  through  C9  syntax  was  introduced  in  Version  2.6 
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Retrieving  Scheduled  Maneuvers 


As  an  author,  you  can  invoke  any  existing  file  of  specified  maneuvers  by  Getting  a  Flight 
Plan  on  the  Scenario  Configuration  screen  (click  on  the  Flight  Plan  name  box,  key  in  the 
name  of  an  existing  flight  plan  file,  and  press  Enter).  When  an  exercise  is  started,  the  system 
will  automatically  produce  the  specified  maneuvers.  You  could  then  change  scenarios,  but 
leave  the  maneuvering  file  the  same,  and  click  on  Begin  again.  The  initial  conditions  would 
change,  according  to  the  new  scenario,  but  the  maneuvers  would  be  the  ‘same’,  i.e.,  the 
limits  specified  would  be  achieved. 

If  you  do  not  want  any  maneuvers  to  be  performed  during  a  problem  run,  as  an  author,  elear 
the  Flight  Plan  box  by  clicking  in  it,  then  pressing  Return.  All  problems  run,  as  an  author, 
will  then  involve  no  maneuvers. 


To  invoke  maneuvers  for  experimental  participants,  include  maneuvering  file  names  in  the 
SessionPlan  file,  as  described  next 


The  Session  Specification  File 

An  experimental  session  is  specified  in  an  ASCII  file  named  SessionPlan  (note  capitalization 
of  file  name).  This  file  lists  predefined  configurations  which  form  the  basis  of  exercises. 
Optionally,  it  can  invoke  previously  defined  scheduled  maneuvers. 

Line  1. 

If  problems  are  not  to  be  generated  randomly,  the  first  line  can  contain  any  text  that  is  usefiil 
in  identifying  the  particular  file  when  it  is  printed.  This  line  is  required. 

Line  2. 

The  second  line  indicates  the  preferences  for  a  session.  Seven  digits  are  entered: 

Digit  1:  Replay  allowed  by  anyone? 

1  means  allow  Replay  by  experimental  participants,  as  well  as  authors 
0  means  allow  Replay  only  by  author 

Digit  2:  Pause  allowed  by  anyone? 

1  means  show  the  Pause  button  regardless  of  the  user’s  name. 

0  means  show  the  Pause  button  only  if  user  is  author 

Digit  3:  Instructional  data  level  (0,  1,  or  2).  See  section  Task  Orientation  and  Instruction. 

Digit  4:  Time  Warp  allowed  by  anyone? 

1  means  respond  to  Time  warp  command  (t  entry)  from  anyone 
0  means  only  respond  to  Time  Warp  command  from  author. 

Digit  5:  Knowledge  of  results  displayed  at  end  of  problems? 

1  means  do  allow  user  to  learn  true  target  identities  at  the  ends  of  problems 
0  means  do  not  provide  true  target  information  at  the  ends  of  problems 

Digit  6:  Performance  score  displayed  at  end  of  problems? 

1  means  do  display  a  score  at  the  end  of  each  problem. 

0  means  do  not  display  a  score  at  the  end  of  each  problem. 
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If  digit  6  is  1,  the  next  line  in  the  SessionPlan  file  must  provide  a  set  of  weights  to  use  in 
computing  the  score,  as  described  in  the  section  Scoring.  _ 


Digit  7:  Scaling  factor  to  use  to  deaease  built-in  delays. 

Delays  up  to  45  seconds  have  been  purposely  built  in  to  the  simulation.  For  example,  after 
warning  a  target  there  is  a  20-second  delay  before  that  target  responds.  This  delay  provides 
high  realism,  but  can  complicate  experimentation  with  novice  operators.  The  experimenter 
may  therefore  enter  a  digit,  fi-om  2  to  9  which  will  factor  the  normal  time  delay  for  each 
activity  type. 

The  author  can  always  replay  problems,  pause/resume  problems,  and  warp  time.  The 
preferences  line  allows  the  experimenter  to  provide  these  options  to  experimental 
participants,  if  desired.  In  most  machine  learning  applications,  particularly  in  runs  used  to 
train  the  learning  system,  the  learning  program’s  performance  is  not  written  to  file.  In  some 
other  cases,  however,  it  may  be  desired  to  capture  the  learning  program’s  performance,  just 
as  if  it  were  a  human  user.  The  third  digit  in  the  preference  line  provides  control  over  this 
function. 

Following  Lines 

The  remaining  lines  in  the  SessionPlan  file,  except  for  the  last  line,  list  names  of  predefined 
configurations  and,  optionally,  scheduled  maneuvers,  as  described  later.  If  the  first  line  of  the 
file  does  not  call  for  random  problem  generation,  the  system  will  produce  exercises  using  the 
listed  configurations  in  order.  In  any  case,  problems  end  when  the  configuration’s  problem 
termination  condition  has  been  met. 

The  last  line  of  the  file  must  be  the  word  end. 


Example  SessionPlan. 


General  Plan  1 
0101101 
My  Scenario  1 
SingleAttack 
OffCourse 
Terrorists 
end 


(problems  will  be  generated  in  the  fixed  sequence  listed  below) 
(the  preferences  for  the  session,  with  no  scoring) 

(the  name  of  the  first  exercise,  or  configuration) 

(the  name  of  the  second  exercise,  or  configuration) 

(the  name  of  the  third  exercise,  or  configuration) 

(the  name  of  the  final  exercise) 

(end  of  file) 


The  second  line  specifies  these  preferences: 

Replay  only  by  authors;  anyone  may  pause/resume;  no  machine  data  written;  anyone  may 
warp  time;  do  allow  user  to  learn  true  target  identities  at  problem  end;  and  do  not  display  a 
performance  score  at  the  end  of  each  problem. 
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Automatic  Problem  Generation 

Problems  can  be  generated  automatically,  either  in  a  systematic  progression  of 
situations,  or  in  a  random  fashion.  In  either  case,  the  automatically  produced  problems 
are  variations  on  predefined  configurations.  The  six  variables  manipulated  are  these: 

•  time  of  day,  2  possible  conditions  (14:00  and  22:00). 

•  radar  clutter  conditions,  3  possible  conditions  (none,  moderate,  heavy) 

•  own  ship’s  equipment  operability 

transmitter,  4  possible  conditions  (OK,  failed,  intermittent,  limited  range) 
receiver,  4  possible  conditions  (OK,  failed,  intermittent,  limited  range) 

•  atmospheric  conditions 

ceiling,  5  possible  conditions  (1000;  5,000;  10,000;  25,000;  and  100,000  feet) 
visibility,  5  possible  conditions  (30, 20, 10,  5,  or  1  mile) 

These  provide  for  2400  different  problems  per  configuration.  Target  characteristics  (the 
number  and  types  of  targets,  their  speeds,  headings,  etc.)  are  not  altered.  Thus,  a 
configuration  can  be  simple  or  complex,  owing  to  the  number  and  types  of  targets,  yet 
it  can  be  made  materially  more  or  less  difficult  by  the  values  selected  for  the  variables. 

When  a  problem  is  generated  with  no  radar  clutter,  none  of  the  clutter  targets  specified 
in  the  basic  configuration  are  displayed.  Under  moderate  conditions,  half  of  the  clutter 
is  shown.  Under  heavy  clutter,  all  the  active  clutter  targets  of  the  configuration  are 
displayed.  Thus  the  maximum  amount  of  clutter  is  determined  within  the  configuration. 
If  a  configuration  has  no  active  clutter  targets,  therefore,  there  will  be  no  clutter  targets 
displayed  regardless  of  the  clutter  conditions  being  used  in  automatic  problem 
generation.  This  approach  allows  the  experimenter  to  custom-position  clutter  targets,  to 
either  simplify  or  complicate  a  problem. 


It  is  recommended  that  at  least  four  clutter  targets  be  provided  if  problems 
will  be  generated  automatically,  so  that  all  problems  wiU  be  different 


Random  Problem  Generation 

To  generate  problems  randomly,  over  all  the  configurations  listed  in  the  SessionPlan 
file,  make  the  first  line  in  the  SessionPlan  file  read  as  follows: 
randomize  <number  of  problems>  <seed> 

where  <number  of  problems>  is  the  total  number  of  problems  to  generate  and  <seed> 
is  either  zero  or  some  positive  integer.  For  example: 
randomize  5000  12345 

The  number  of  problems  can  be  any  integer.  If  seed  is  zero,  the  system  will  initialize 
random  number  generation  using  the  system  clock,  thus  the  sequence  of  problems  is 
not  repeatable  from  one  session  to  another.  If  seed  is  not  zero,  the  system  will  initialize 
the  random  number  generator  using  seed,  thus  the  problems  will  be  generated 
randomly,  but  in  a  repeatable  manner.  Random  selection  is  with  replacement,  but  the 
system  never  selects  the  same  configuration  twice  in  a  row. 
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Whenever  problems  are  generated  randomly,  the  system  creates  a  file  named  scratchFile. 
This  file  can  be  removed  anytime  sessions  are  not  in  progress. 

Example: 

randomize  3500  5432  (randomly  generate  3500  problems,  with  seed  5432) 

010100 

My  Scenario  1 

SingleAttack 

OffCourse 

Terrorist3 

end 

Sequential  Problem  Generation 

Problems  can  also  be  generated  in  a  sequential  fashion,  each  being  a  systematic  variation  of 
its  basic  configuration.  To  generate  problems  sequentially,  add  the  number  of  problems  to  be 
generated  to  any  configuration  named  in  the  SessionPlan  file  (add  1  space  then  the  number  of 
problems).  Example: 

Session  Plan  2 
0101001 
MyScenariol  20 
SingleAttack  8 
end 

Specifying  Scheduled  Maneuvers  in  the  Session 

To  effect  scheduled  maneuvers  during  a  problem,  add  the  symbol  '+’  and  a  scheduled 
maneuver  file  name  to  any  configuration  line  (no  embedded  blanks).  For  example,  the 
following  SessionPlan  file  calls  for  making  the  maneuvers  specified  in  the  file  scary  on  the 
first  two  problems,  and  the  maneuvers  from  sneaky  on  the  last  10  problems: 

Session  Plan  3 
010110 

MyScenariol +scary  (run  MyScenariol  with  scary  maneuvers,  once) 

OffCoiuse  5  (run  OffCourse  with  no  maneuvers,  with  5  variations) 

Terrorist3+sneaky  10  (run  Terrorist3  with  sneaky  maneuvers,  10  variations) 

end 


(problems  not  generated  randomly) 
(preferences;  no  scoring) 

(run  20  problems  with  this  configuration) 
(then  run  8  problems  with  this  configuration) 


Replaying  Exercises 

The  author  can  always  replay  completed  exercises,  and  experimental  participants  may 
do  so  if  the  preferences  in  the  SessionPlan  file  allow.  The  option  exists  to  either  replay 
the  just-completed  exercise,  or  any  other  previously-completed  exercise.  Thus,  the 
replay  capability  provides  a  way  for  an  instructor  to  ‘demonstrate’  expert  performance 
and  have  others  observe  that  captured  performance  at  another  time  and  place. 

To  replay  a  problem  do  this: 

a.  Upon  completion  of  a  problem,  press  the  ‘r’  key,  and  observe  the  replay  box. 
Replay:  Previous  Problem 


b.  To  replay  an  exercise  other  than  the  previous  one,  key  in  the  exercise  name  (click  on 
Previous  Problem,  key  in  the  name  of  a  file  that  contains  the  data  for  a  previously- 
completed  exercise,  press  Enter).  Otherwise,  proceed  to  step  c. 

c.  Press  Begin,  and  watch  the  problem  play  out  as  just  performed.  You  will  observe  a 
message  that  indicates  each  action  performed  by  the  user,  and  you  will  see  the  influence 
of  that  action  on  the  simulation. 

Replay:  Previous  Problem 

Hook  target  1122 _ _ _ 


Problems  may  be  replayed  multiple  times  by  pressing  Begin  with  the  replay  box 
visible.  Problems  may  be  Paused  during  replays,  if  desired.  To  start  a  new  problem, 
press  the  r  key  to  make  the  replay  box  disappear,  then  click  on  Begin. 

Scoring  the  User’s  Performance 

To  display  a  performance  score  at  the  end  of  each  exercise,  set  digit  6  of  the  preference 
line  to  “1”.  The  performance  score  is  calculated  automatically  by  the  simulation  system, 
as: 

score  = 

wl 

+  w2  *  closest  hostile  target 

-  w3  *  firings  on  friendly  targets 

-  w4  *  firings  on  hostile  targets  that  would  heed  warnings 

-  w5  *  warnings  at  level  1  issued 

-  w6  *  warnings  at  level  2  issued 

-  w7  *  warnings  at  level  3  issued 

-  w8  *  warning  shots  fired  at  friendly  craft 

-  w9  *  warning  shots  fired  at  hostile  craft 

-  wlO  *  illuminations  of  friendly  craft 

-  wl  1  *  illiuninations  of  hostile  craft 

-wl2  *  number  of  attacks  by  hostile  craft  (0  or  1) 

where  the  coefficients  wl  through  wl2  are  weights  that  apply  to  scoring  during  the 
session.  Any  of  the  weights  may  be  set  to  0. 
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If  digit  6  of  the  preference  line  in  the  SessionPlan  file  is  “1”,  then  the  line  following  the 
preferences  line  must  supply  the  weights,  a  36-digit  number,  representing  twelve  3-digit 
weights,  e.g., 

05(X)2(X)5002()()0()(X)2(X)3020()0501()0()01()0 

The  following  is  an  example  SessionPlan  file  calling  for  scoring: 

randomize  250  0  (generate  250  problems  randomly) 

010101 1  (preferences:  scoring  enabled) 

025020020050000002003020005025000100  (scoring  weights) 

MyScenariol 

OflPCourse 

Terrorist2 

end 

The  Scoring  Algorithm 

The  primary  objectives  of  the  exercise  are  to  minimize  threat  to  own  ship  from  other  craft 
while  avoiding  inappropriate  defensive  actions.  Secondarily,  the  more  skilled  decision¬ 
maker  will  limit  intrusive  threats  or  warnings  to  situations  deserving  them,  while  less-skilled 
decision-makers  may  employ  such  actions  inappropriately.  The  structure  of  the  scoring 
algorithm  is  set  up  to  recognize  both  the  primary  and  secondary  factors. 

The  scoring  algorithm  provides  the  experimenter  considerable  flexibility  in  weighting 
various  actions.  Its  basic  structure  provides  the  ability  to  begin  an  exercise  with  a  constant 
score  (wl),  to  add  to  this  constant  according  to  the  user’s  ability  in  keeping  hostile  craft 
away  (w2),  and  to  subtract  from  this  according  to  the  occurrence  of  undesirable  events.  By 
assigning  proper  weights,  the  experimenter  can  discourage  overuse  of  warnings  (including 
illuminations),  even  though  issuing  of  warnings  is  not  inherently  negative.  In  essence, 
warnings  can  be  employed  at  some  ‘cost’  as  an  investment  to  keep  the  score  high  by 
avoiding  approach  or  attacks  by  threatening  craft  or  taking  inappropriate  defensive  measures. 
The  ‘costs’  associated  with  contacting  land-based  towers  or  calling  for  visual  identifications 
are  not  included  in  the  score.  These  actions,  if  overused,  consume  the  user’s  time  and 
attention,  but  if  used  properly  can  assist  in  conducting  the  task  well. 

Specifying  Commercial  Air  Routes 

The  simulation  provides  six  commercial  air  routes,  shown  as  dotted  orange  lines  when  the 
user  sets  the  Commercial  Air  Routes  check  box  in  the  Display  section  to  checked.  The  author 
can  control  which  of  the  six  air  routes  are  displayed  during  authoring  by  checking  the  routes 
desired  on  the  Scenario  Configuration  Screen.  Tlie  figure  below  provides  the  numbers  of  the 
six  routes  between  the  six  airports. 

In  general,  increasing  route  numbers  relate  to  increasingly  threatening  courses.  The  selection 
of  air  routes  is  independent  of  scenario  configuration,  i.e.,  any  configuration  can  be  run  with 
any  assortment  of  commercial  air  routes. 

The  experimenter  may  call  for  any  mix  of  the  six  routes  to  be  involved  in  a  problem,  using 
an  input  line  starting  with  the  word  routes,  within  the  SessionPlan  file.  The  following  is  an 
example:  routes  00101 1 
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This  particular  input  causes  air  routes  3,  5,  and  6  to  display  when  the  air  routes  box  is 
checked  by  the  user.  The  input  line  must  be  exactly  as  shown,  with  one  space  following  the 
word  routes,  then  6  digits  that  are  0  or  1.  Authors  are  responsible  for  setting  up  the 
commercial  airliners  to  follow  the  routes  or  not,  as  they  like. 


Multiple  routes  input  lines  can  be  embedded  in  the  SessionPlan  file.  Each  one  establishes  the 
air  routes  that  will  be  shown  (when  requested)  until  the  next  routes  input  line,  if  any.  The 
first  routes  input  line  must  come  somewhere  after  the  preferences  line  and  its  following 
weights  line,  if  any.  The  following  is  an  example: 


Plans 

0101111  (preferences) 

025020020050000002003020005025000100  (scoring  weights) 
routes  1 1 1000  (enable  only  commercial  air  routes  1 ,  2,  and  3) 

MyScenariol+scary  (run  MyScenariol  with  scary  maneuvers,  once) 

routes  100001  (enable  only  commercial  air  routes  1  and  6) 

OffCourse  5  (run  OffCourse  with  no  maneuvers,  in  5  variations) 

Terrorist3+sneaky  10  (run  Terrorist3  with  sneaky  maneuvers,  10  variations) 

end 


Thus,  in  the  foregoing  SessionPlan  file,  routes  1 ,  2,  and  3  are  enabled  (displayable)  for  the 
first  problem,  while  routes  1  and  6  are  enabled  for  the  following  fifteen  problems. 

The  system  enables  all  six  routes  by  default  at  the  start  of  an  experimental  session,  in  case 
problems  are  run  with  no  preceding  routes  specification. 
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Specifying  Airport  Names 

The  author  can  set  the  names  of  the  six  airports  involved  in  commercial  air  travel.  To 
association  different  names  with  each  scenario,  define  them  and  save  them  as  outlined 
earlier.  Alternatively  the  author  may  define  a  set  of  names  to  be  used  for  an  entire 
session  (until  or  unless  a  scenario  is  run  that  provides  its  own  names;  in  this  case  these 
newer  names  are  used  until  overridden  by  another  scenario  containing  custom  names). 

To  define  names  to  be  used  for  a  session,  create  a  text  file  named  portNames,  entering 
one  name  per  line.  The  names  are  assigned  in  the  order  listed  to  airportA,  airportB, ..., 
airportF  as  shown  in  the  preceding  diagram. 

Example: 

Milwaukee 

San  Francisco 

Gerberville 

Paris 

Nome 

Akron 


Printing 

The  simulation  screen  may  be  printed  at  any  time  using  the  print  menu  item  under 
View,  however  the  proper  print  command  may  vary  from  one  installation  to  another. 
Each  user  should  key  in  whatever  Unix  print  command  works  for  the  system  involved. 

The  default  print  line  works  for  SCO  Unix. 

For  Linux  users,  complete  the  print  command  to  read: 

Ip  -o  raw  -d  Ip 
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Machine  Learning  Mode 

The  CIC  simulation  can  be  set  up  to  communicate  bi-directionally  with  a  machine 
learning  program,  hosted  either  in  the  same  platform  or  over  a  network.  The  ‘setup’  is 
accomplished  simply  by  entering  the  name  ‘machine’  to  the  CIC  system  when  it  is 
started. 

Two  data  files,  MLData  and  Status,  are  used  for  inter-processor  communication.  File 
MLData  is  used  by  CIC  to  inform  the  machine  learning  system  about  the  progress  of  a 
scenario,  and  it  is  used  by  machine  learning  models  to  communicate  decisions  back  to 
CIC.  The  Status  file  is  used  to  control  and  mark  who  has  control  of  the  process.  When 
CIC  is  ready  to  turn  control  over  to  machine  learning,  it  writes  “GOML”  into  Status 
(this  will  be  the  only  record  in  the  file).  When  machine  learning  is  ready  to  turn  control 
back  to  CIC  (after  writing  out  its  decision  to  the  MLData  file),  it  writes  “GOCIC”  as  the 
only  record  in  Status. 

Data  Communicated  to  the  Machine  Learning  System 

In  machine  learning  mode  the  CIC  system  communicates  four  kinds  of  data  to  the 
outside  world;  1)  initial  conditions,  2)  periodic  updates  which  provide  current 
information  about  the  simulated  world,  3)  actions  performed  by  other  simulated  people 
in  the  scenario,  and  4)  an  end-of-problem  marker. 

Initial  Conditions.  At  the  start  of  each  problem,  the  CIC  system  writes  out  to  the 
MLData  file  a  complete  image  of  the  starting  conditions  of  the  scenario.  This  block  of 
data  starts  with  the  record  “MLData”,  and  ends  with  the  specifications  for  each  active 
target,  plus  clutter,  in  the  exercise.  Note  that  this  initial  header  data  does  not  start  with 
the  code  “01”  that  precedes  all  subsequent  periodic  updates. 

Periodic  Updates.  Every  few  seconds  during  the  simulation  the  CIC  system  writes  out 
to  the  MLData  file  a  complete  ‘snapshot’  of  the  scenario  at  that  instant  This  file  write  is 
done  each  time  the  graphical  display  is  updated,  i.e.,  the  machine  learning  system  will 
receive  the  same  information,  in  data  form,  that  a  human  operator  would  perceive 
visually.  The  data  format  of  the  MLData  file  is  that  described  under  Periodic  Updates, 
above  (each  periodic  update  starts  with  a  record  “01”  followed  by  the  update  time). 

Actions  of  Others.  The  CIC  system  also  broadcasts  the  performance  of  actions  by 
people  other  than  the  decision-maker.  These  actions  are: 


Action 

Code 

the  warned  target  repHes 

04 

the  crew  returns  a  visual  identification 

08 

a  land-based  tower  responds  to  a  query 

10 

a  hostile  target  fires  on  own-ship 

50 

Other  characters  follow  these  codes,  giving  the  time  of  occurrence,  and  if  appropriate 
the  track  number  of  the  acting  target.  See  section  Replies  and  Target  Actions  for  the 
complete  formats.  If  the  machine  learning  system  needs  to  know  exactly  what  a  warned 
target  says  when  it  replies,  it  can  refer  to  the  ASCII  file  which  generated  that  text  (file 
CICDescriptions),  in  reference  to  the  configuration  being  run  (which  is  specified  in  the 
configuration  file). 
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End-of-Prnhlem  Marker.  At  the  conclusion  of  each  problem,  the  CIC  system  writes 
the  code  “99”,  followed  by  the  total  elapsed  exercise  time,  and  the  performance  score, 
to  MLData.  At  this  point,  the  machine  learning  system  can  write  out  any  data  files  it 
uses,  and  it  can  prepare  to  start  the  next  problem.  When  it  is  ready  to  proceed,  it  should 
write  action  code  “00”  to  MLData,  then  write  “GCXHIC”  to  file  Status. 

Turn  Taking 

At  startup,  the  machine  learning  system  should  write  “WAIT’  to  the  Status  file,  then 
monitor  that  file  until  it  contains  the  record  “GOML”.  Thus,  the  CIC  system  has  the 
first  real  ‘turn’.  The  initial  data  that  CIC  writes  to  the  file  MLData  describes  the  initial 
scenario  conditions.  Following  each  write  to  MLData,  the  CIC  system  pauses  until  the 
machine  learning  system  responds.  During  this  pause,  there  is  no  activity  in  the 
simulation  whatsoever,  and  passage  of  time  is  ignored. 

The  machine  learning  system  can  detect  that  new  information  is  available  for  analysis  if 
the  first  and  only  record  of  the  Status  file  is  “GOML”.  In  this  case,  the  machine 
learning  system  can  read  in  the  complete  MLData  file,  and  it  can  take  as  much  time  as 
necessary  to  digest  the  situation.  Then  it  should: 

1.  write  out  a  single  record  to  the  MLData  file,  indicating  its  decision, 
and  then 

2.  write  the  record  “GOCIC”  to  the  Status  file. 

As  soon  as  the  machine  learning  system  writes  the  “GOCIC”  record  to  the  Status  file, 
the  CIC  simulation  acts  on  any  decision  residing  in  MLData,  and  it  resumes  simulating 
imtil  it  is  time  to  inform  machine  learning  again. 

Communicating  Machine  Learning  Decisions 

Each  machine  learning  decision  is  represented  via  a  2-character  ASCII  decision-code, 
followed  by  a  few  extra  characters  for  action  codes  “02”  and  “03”.  The  action  codes  are 
shown  in  the  table  below  (‘hooked  target’  signifies  the  most  recently  hooked  aircraft  or 
sea  vessel). 


Action 

Code 

Plus 

No  action  (continue  with  scenario) 

00 

Hook  a  new  target 

02 

4-character  track  # 

Warn  the  hooked  target 

03 

level  (1,2,3)  &  channel  (1,2) 

Fire  warning  shots  at  the  hooked  target 

05 

Illuminate  the  hooked  target 

06 

Request  visual  ID  of  the  hooked  target 

07 

Contact  tower  regarding  hooked  target 

09 

Fire  at  the  hooked  target 

60 

These  data  are  ASCII  characters. 

Two  action  types,  hook  target  and  warn  target,  require  a  few  extra  digits,  as  explained 
next. 
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Hooking  fSelficting)  Targets.  Prior  to  performing  any  action  involving  a  target,  the 
decision-maker  must  identify,  or  ‘hook’  the  target  to  be  acted  upon.  To  hook  a  target,  write  a 
record  starting  with  ‘02’,  followed  by  the  target’s  4-character  track  number,  e.g.,  021524 
means  hook  target  1524.  Then,  at  each  decision  opportunity,  the  machine  learning  system 
can  call  out  an  action  to  take  upon  the  hooked  target.  To  act  on  another  target,  perform 
another  hooking  action,  supplying  the  new  track  number. 

Warning  Targets.  To  warn  the  hooked  target,  write  a  record  starting  with  ‘03’,  followed  by 
the  character  ‘1’,  ‘2’,  or  ‘3’,  signifying  the  warning  level,  and  the  character  ‘1’  or  ‘2’, 
signifying  the  radio  channel  (MAD  is  ‘1’,  lAD  is  ‘2’),  e.g., 

0321  means  warn  the  hooked  target  at  level  2,  on  the  MAD  channel 

Examples 

021053  hook  target  1053 

05  fire  warning  shots  near  hooked  target 

0321  warn  the  hooked  target  at  level  2,  on  the  MAD  channel 

60  fire  on  the  hooked  target 

Starting  A  Machine  Learning  Session 

Start  your  machine  learning  system  first.  Then  start  the  CIC  simulation,  entering  “machine” 
as  the  user  name,  and  then  click  on  the  Proceed  button.  All  processing  after  this  point  is 
automatic.  Warning:  do  not  use  the  mouse  during  a  machine  learning  session. 

Your  machine  learning  system  should  follow  these  procedures: 

1.  At  start  up,  write  “WAIT’  to  the  Status  file. 

2.  Monitor  the  Status  file  until  it  reads  “GOML”  or  “STOP”. 

3.  If  STOP,  the  session  is  done.  If  GOML,  compute  a  decision  and  write  out  the  appropriate 
action  code  to  MLData. 

4.  Write  “GOCIC”  to  the  Status  file  (one  record,  destructive  write). 

5.  Go  back  to  step  2. 

If  the  machine  learning  system  wants  to  stop,  it  should  write  “STOP”  to  Status  at  step  3,  then 
do  step  4,  then  it  should  wrap-up  its  own  business  and  then  stop.  Alternatively,  it  could 
simply  stop  at  step  3,  leaving  CIC  in  a  waiting  condition. 

Restarting  Machine  Learning  Sessions 

The  machine  learning  system  can  restart  a  session  automatically  by  writing  the  key  word 
‘RESTART’  to  the  Status  file.  A  new  CIC  session  will  then  commence. 

Testing  Communications 

To  facilitate  testing  of  a  machine  learning  configuration,  a  second  RIDES  program,  testML, 
is  provided.  This  routine  allows  you  to  make  decisions  manually  that  are  then  communicated 
to  the  CIC  simulation,  and  it  receives  and  displays  the  first  record  of  each  data  dump  which 
CIC  makes  to  the  MLData  file. 

Using  testML,  you  can  manually  perform  these  actions: 

o  hook  either  of  two  targets,  (the  ‘first’  being  whatever  target  happens  to  be  listed  as  the  first 
target  in  the  scenario,  and  the  ‘second’  being  the  target) 
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•  warn  the  hooked  target  (level  2  and  the  MAD  channel  are  assumed); 

•  contact  the  tower  about  the  hooked  target; 

•  request  a  visual  ID  about  the  hooked  target;  and 

•  continue  simulating  (no  action  at  this  time). 

Your  machine  learning  system  can  invoke  other  actions,  but  these  are  sufficient  to  test 
the  communication  channels  with  CIC. 

Here  is  the  procedure  for  using  testML  with  CIC. 

1.  Launch  testML  and  CIC  in  any  order,  but  don’t  start  either  one. 

2.  Start  testML  by  clicking  on  its  Start  button.  Its  Start  button  turns  red. 

Observe:  Waiting  for  initial  conditions  from  CIC, 

3.  Enter  “machine”  as  CIC’s  user  name,  if  it  is  not  already  there,  and  click  on  Proceed. 

4.  After  5-10  seconds,  the  radar  simulation  screen  will  appear,  CIC  will  write  out  the 
initial  conditions  to  MLData,  and  testML  will  display: 

Initial  Conditions  received;  continue. 

5.  Click  on  the  bottom  button,  labeled  “continue  simulating”.  Each  time  a  decision  is 
indicated  via  a  radio  button,  the  buttons  will  disappear. 

6.  The  CIC  simulation  will  display  ML  decision:  00  and  it  will  make  its  first  update 
to  the  scenario  and  write  out  a  periodic  update  to  MLData. 

7.  Now  you  will  see  the  first  record  of  the  update  in  testML,  something  like  01  4 

meaning  a  periodic  update  at  4  seconds.  If  you  like,  you  can  bring  up  the  entire 
MLData  file  in  a  text  editor  and  observe  the  fuU  contents. 

8.  From  this  point  on,  you  may  make  any  of  the  decisions  supported  by  testML  by 
clicking  on  one  of  the  radio  buttons.  Following  each  decision,  CIC  will  display  the 
exact  action  code  it  receives,  it  will  update  the  scenario,  it  will  write  out  a  periodic 
update  or  a  response  to  one  of  your  actions  (a  reply  from  a  warned  target,  a  tower, 
or  the  crew  member  making  a  visual  ID),  and  it  will  pause,  waiting  for  another 
decision. 

At  the  end  of  a  problem,  you  will  see  the  code  99  followed  by  the  time.  Click  on 
proceed.  If  your  sessionPlan  file  lists  more  than  one  problem,  CIC  will  start 
running  the  next  problem.  To  end  a  test  session,  click  on  the  testML  Stop  button. 
While  testML  can  be  restarted  simply  by  clicking  on  the  Start  button  again,  the  CIC 
system  must  be  restarted  from  the  beginning,  i.e.,  at  the  initial  user  identification 
screen. 

Testing  Machine  Learning 

The  machine  learning  system  has  access  to  all  of  the  data  involved  in  a  scenario  (initial 
conditions,  periodic  updates,  and  actions  by  others),  as  well  as  its  own  decisions. 
Since  execution  time  is  of  no  consequence  during  the  machine  learning  control  phase,  it 
can  write  out  whatever  data  is  useful  to  fully  document  the  exercise.  Note  that  the  CIC 
system  does  not  write  out  exercise  data  to  any  other  file  than  MLData,  in  machine 
learning  mode. 

If  desired,  experimenters  may  observe  the  scenario  while  it  is  being  run  in  association 
with  a  machine  learning  system.  For  convenience,  the  CIC  system  displays  each 
decision  that  it  receives  in  the  lower  user  prompt  area,  in  red  letters,  e.g., 

ML  decision  :  021534 
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Task  Orientation  and  Instruction 


Content 

At  the  experimenter’s  discretion,  orientation  and  instruction  in  the  tactical  decision  making  task 
can  be  made  available  to  a  user.  The  SessionPlan  file  is  used  to  specify  when  and  if  instruction 
is  available  and  the  level  of  detail  recorded  about  the  user’s  study  of  the  material. 

The  instruction  covers  eleven  topics.  The  content  is  very  fundamental,  addressing  the  basic 
task  objectives,  the  mechanics  of  operating  and  interpreting  the  simulated  display,  and  the 
means  and  implications  of  issuing  the  various  commands.  The  following  table  indicates  the 
topics. 


Topic 

ilHHHii 

Task  Objectives 

2 

3 

Target  Symbols 

4 

Controlling  the  Radar  Display 

5 

Hooking  Targets 

6 

Warning  Targets 

7 

Clearing  and  Restoring  Targets 

8 

Identifying  Targets 

9 

Acting  on  Targets 

10 

Begin,  Pause,  Help,  and  Replay 

11 

Exercise  Conditions  &  Results 

Because  this  task  will  be  used  under  widely  vaiying  experimental  conditions,  there  are  two 
topics  intentionally  not  discussed:  1)  the  specific  scoring  that  will  be  used,  if  any,  to  measure 
the  user’s  proficiency,  and  2)  geopolitical  issues  that  affect  the  conduct  of  the  task.  These  two 
topics  may  be  addressed  off-line,  according  to  the  conditions  of  the  particular  experiment 

In  order  to  maximize  the  significance  of  the  collected  data,  the  user  accesses  a  topic  only  by 
clicking  on  the  topic  name  specifically.  While  other  ‘browsing’  features,  such  as  forward  and 
backward  arrows  could  be  provided,  they  would  make  data  interpretation  more  difficult  since 
screens  could  be  accessed  that  were  not  sought 

The  experimenter  controls  when  and  if  instruction  is  to  be  made  available  to  the  user  and  the 
level  of  detail  in  the  recorded  usage  data.  This  is  done  by  setting  digit  three  of  the  session 
preferences  line  in  the  SessionPlan  file.  If  the  Pause  mode  is  disabled  when  instruction  is 
allowed,  then  instruction  is  only  available  between  exercises.  If  Pause  mode  is  enabled  and 
instruction  is  allowed,  then  the  user  can  access  the  instructional  content  during  pauses  in 
exercises  as  well  as  between  exercises.  The  particular  number  entered  in  the  Preferences  line 
determines  whether  usage  of  instruction  is  recorded  at  a  summary  level  or  at  a  detailed  level. 
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Controlling  Availability  of  Task  Instruction 

There  are  three  alternatives  for  the  availability  of  instruction  during  a  session: 

1.  Instruction  is  not  available. 

Set  digit  three  to  0.  The  Help  button  which  evokes  instruction  will  not  be  visible  to  the  user, 
and  no  instruction  usage  data  will  be  written. 

2.  Instruction  is  available  between  exercises. 

Set  digit  three  to  1  or  2,  and  disable  Pause  mode  by  setting  digit  two  to  0.  A  Help  button  will 
appear  on  the  simulation  screen  before  each  exercise,  including  the  first,  providing  access  to 
the  instruction.  If  the  digit  entered  is  ‘T,  summary  level  data  will  be  recorded  for  each 
exercise.  If  the  digit  is  ‘2’,  detailed  data  will  be  recorded  for  each  exercise. 

3.  Instruction  is  available  between  exercises,  and  during  Pauses  within  exercises. 

Set  digit  three  to  1  or  2,  and  enable  Pause  mode  by  setting  digit  two  to  1.  The  Help  button  will 
be  visible  prior  to  each  exercise,  and  whenever  an  ongoing  exercise  is  paused  by  the  user.  As 
above,  a  ‘T  for  digit  three  signifies  summary  data,  a  ‘2’  signifies  detailed  data. 

Usage  Data 

Summary  Level  Data.  If  summary  level  data  is  specified,  usage  of  the  instructional  material 
during  a  session  is  recorded  entirely  in  a  data  file  named  <user  name>.instn,  e.g., 

Smith.instn. 

If  Pause  mode  is  disabled,  there  will  be  two  records  per  exercise  in  the  data  file.  For  each 
exercise  performed,  one  record  gives  the  exercise  number,  and  the  next  indicates  the  total 
seconds  devoted  to  each  topic  prior  to  that  exercise.  Each  data  record  consists  of  eleven  4-digit 
numbers  preceded  by  one  blank,  as  shown  in  the  following  example: 


Exercise  01 

0093  0403  0654 
Exercise  02 

0000 

0000 

0000 

1532 

0000 

0083 

0392 

0043 

0064  0329  0423 
etc. 

0040 

0055 

0050 

0055 

0680 

0064 

0035 

0465 

This  user  spent  423  seconds  studying  topic  3  prior  to  exercise  2. 

If  Pause  mode  is  enabled,  there  will  be  three  records  per  exercise  in  the  data  file:  the  first  record 
is  the  exercise  header,  the  second  gives  the  study  times  prior  to  the  exercise,  the  third  gives  the 
times  spent  studying  during  Pauses  within  the  exercise. 


Exercise  01 

0093  0403  0654 

0000 

0000 

0000 

1532 

0000 

0083 

0392 

0043 

(prior  to) 

0000  0000  0093 

0000 

0000 

0030 

0000 

0000 

0000 

0112 

0000 

(during) 

Exercise  02 

0064  0329  0423 

0040 

0055 

0050 

0055 

0680 

0064 

0035 

0465 

0093  0403  0654 

0000 

0000 

0000 

1532 

0000 

0083 

0392 

0043 

etc. 

In  this  example,  we  know  that  the  user  spent  30  seconds  studying  the  sixth  topic  during  pauses 
in  exercise  one,  but  we  don’t  know  when  in  the  exercise  this  occurred,  or  how  many  times  this 
topic  was  studied.  To  know  this,  we  use  detailed  recording. 
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Dfttailftd  Data.  If  Pause  mode  is  disabled,  all  detailed  data  records  are  written  to  the  user.instn 
file.  The  detailed  data  provides  the  same  summary  information  described  above,  but  m  addition 
it  indicates  each  usage  of  the  instructional  screens.  Each  usage  record  reflects  the  topic  (screen) 
number  studied,  and  the  seconds  spent  in  the  following  format: 

<topic  number,  3  digits>,  space,  <total  seconds,  4  digits> 

Following  the  detailed  usage  records  is  a  record  starting  with  ‘999’,  indicating  that  the  next 
record  is  a  summary  record.  The  data  records  for  the  first  three  exercises  of  an  example  session 
are  shown  below  (records  for  the  first  exercise  are  annotated). 


Exercise 
004  0058 
003  0014 
008  0156 
003  0063 
999  0000 
0000  0000 


(user  spent  58  seconds  on  screen  4) 

(user  spent  14  seconds  on  screen  3) 

(user  spent  156  seconds  on  screen  8) 

(user  spent  63  seconds  on  screen  3) 

(end  of  detailed  records) 

0077  0058  0000  0000  0000  0156  0000  0000  0000 


Exercise  02 
999  0000 

0000  0000  0000  0000  0000  0000  0000  0000  0000  0000  0000 
Exercise  03 


002  0038 
005  0017 
006  0375 
007  0043 
999  0000 

0000  0038  0000  0000  0017  0375  0043  0000  0000  0000  0000 


(summary) 


Note  that  the  Exercise  header,  the  end  marker,  and  the  summary  record  are  written, 
even  if  the  user  did  not  access  the  instructional  screens  prior  to  an  exercise  (as  in 
Exercise  2,  above). 


If  Pause  mode  is  enabled,  the  detailed  usage  data  file  will  reflect  the  usage  of  instruction  prior 
to  each  exercise,  and  the  user’s  task  performance  data  files  will  contain  records  showing  use  of 
the  instructional  screens  while  in  Pause  mode. 

A  new  action  code,  31,  is  used  to  document  the  start  of  an  instructional  activity,  while  in  pause 
mode  of  an  exercise.  ITie  instructional  activity  records  are  embedded  in  the  user’s  performance 
data  file  for  the  convenience  of  analyzing  the  data.  Note,  however,  that  in  Pause  mode,  the 
simulation  clock  is  not  running.  For  this  reason,  the  times  spent  studying  instructional  material 
are  not  reflected  in  the  cumulative  times  of  the  periodic  updates,  and  other  normal  performance 
records. 

The  following  annotated  example  illustrates  a  section  of  a  user’s  performance  data  file  when 
detailed  recording  was  requested  and  the  user  accessed  instruction  during  a  pause  in  an 
exercise. 
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01  85  (a  periodic  update  of  three  active  targets) 

1024  045  043  001050  0445  124  u 

1134  151  018  024800  0266  090  f 

1543  018  009  000000  0012  245  f 

31  98  (the  user  clicked  on  Help,  while  the  exercise  was  Paused  at  98  seconds) 

004  0058  (user  spent  58  seconds  on  screen  4) 

003  0014  (user  spent  14  seconds  on  screen  3) 

008  0156  (user  spent  156  seconds  on  screen  8) 

999  0000  (user  exited  instructional  screens) 

01  89  (a  periodic  update) 

etc. 


When  analyzing  these  data,  note  that  the  user  could  go  to  instructional  screens,  return  to  the 
simulation,  then  go  to  the  instructional  screens  again  before  resuming  the  simulation. 

Appendix  E  provides  screen  graphics  for  the  instructional  content. 
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Appendix  A 

Targets  Provided 

The  CIC  simulation  is  stocked  with  the  following  targets: 


Target  Type 

Qty- _ 

aircraft 

surface  vessels 

15 

submarines 

3 

clutter 

20 

The  experimenter  may  employ  any  subset  of  these  targets  in  a  particular  exercise,  and 
may  configure  all  aspects  of  each  target,  except  that  target  type  is  fixed  for  each  target. 


Appendix  B 


Built-in  Delays 

One  of  the  difficulties  in  using  any  complex  man-machine  system  is  the  problem  that 
commands,  inquiries,  and  responses  all  consume  time —  there  are  significant  delays  in  crew 
member  responses  to  commands,  and  in  responses  by  targets  to  actions  taken  by  the 
decision-maker.  The  following  lists  the  delays  that  are  intentionally  built-in  to  the  CIC 
simulation  to  maintain  high  realism. 


Defend  Ship 
Illuminate  Target 
Contact  Tower 
Visual  ID 
Warn  Target 
Fire  Warning  Shots 


15  seconds  to  fire  at  hooked  target,  following  the  order 
45  seconds  for  illuminated  target  to  respond,  if  it  does  respond 
30  seconds  for  tower  to  respond. 

10  seconds  for  crew  to  attempt  identification  of  hooked  target 
20  seconds  for  target  to  respond,  if  it  does  respond 
30  seconds  to  fire  shots,  following  the  order 


Scaling 

Digit  7  of  the  Preferences  line  (line  2)  of  the  SessionPlan  file  provides  a  means  for  scaling  these 
delays  from  1/2  to  1/9  of  the  nominal  values  shown  above. 


Appendix  C 

Summary  of  Key  Commands 

The  following  keys  can  be  pressed  by  the  author  to  effect  various  authoring  functions: 

c  Shows/hides  the  target  configuration  box;  used  to  configure  selected  targets, 
f  Shows/hides  the  fly-by-wire  controls;  used  to  set  target  speed,  heading,  altitude, 
m  Used  to  move  the  selected  target;  click  at  the  new  position  while  holding  down  m. 
r  Shows/hides  the  exercise  Replay  box. 
s  Shows/hides  the  Scenario  configuration  screen, 
t  Shows/hides  the  time  warp  control;  used  to  accelerate  testing. 

V  Shows/hides  inactive  targets,  for  the  current  configuration. 

X  Shows/hides  the  target  debriefing  box.  _ 

The  experimenter  can  also  allow  study  participants  to  use  the  r  and  t  commands. 
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Appendix  D 

Supplied  Configurations 

The  following  configurations  are  supplied  with  the  CIC  simulation  software: 


1  configuration  Name 

Nature  of  the  Configuration 

All  targets  are  active  and  arranged  by  target  type 

configl 

Approximately  half  of  the  targets  are  active 

configS 

No  targets  are  active 

config4 

A  commercial  airliner  approaching 

configS 

An  attack  by  a  military  aircraft 

These  configurations  simply  provide  helpful  starting  points  to  create  custom 
configurations.  If  a  configuration  will  employ  most  of  the  available  target  types, 
configl  provides  a  useful  basis.  If  very  few  targets  will  be  involved,  start  with  configS, 
and  move  the  targets  desired  onto  the  radar  screen.  Config4  and  configS  provide 
samples  of  configurations  that  could  be  used  for  experimentation. 

In  configuration  configl,  config2,  and  configS,  the  targets  are  set  up  as  follows: 


Tracks 

Will  Fire? 

Will  Heed? 

1035,  37,  39,  41 

small  private  aircraft 

no 

yes 

1043,  45,  47,  49,  51 

commercial  airliner 

no 

yes 

1053,  55,  57,  59 

no 

yes 

1061,  63,  65 

hostile  military  aircraft 

yes 

yes 

1067,  69,  71 

hostile  military  aircraft 

yes 

no 

1073 

comm’l  airliner  w/  no  radio 

no 

not  to  radio 

1122 

friendly  submarine 

no 

no 

1123 

hostile  submarine 

yes 

yes 

1124 

hostile  submarine 

yes 

no 

1234,  44,  54 

RSTTiRinilSRRrJilSifl^ 

no 

yes 

1236,  46,  56 

hostile  ship 

yes 

no 

1238,  48,  58 

no 

yes 

1240,  50,  60 

friendly  military  ship 

no 

yes 

1242,  52,  62 

hostile  ship 

_ YB. _ 

yes 

These  characteristics  exist  in  relation  to  the  CICDescriptions  file,  which  has  these 
entries  (individual  users  of  the  software  may  be  using  different  descriptions  in  their 
file): 
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Record 

Description 

1 

small  private  aircraft 

commercial  fishing  shi 


military  fighter 


military  aircraft  of  unknown  ongm 


rivate  helicopter 


commercial  airliner  _ 


friendly  submarine 


submarine  of  unknown  ongm 


hostile  submarine 


ship  from  hostile  nation 


clutter 


U.S.  military  aircraft 


hostile  aircraft 


Appendix  E 


Instructional  Screens 

The  following  pages  are  screen  prints  of  the  instructional  screens  provided. 
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Topics 


Click  on  the  topic  you  wish  to  study. 


Click  below  to  continue  with  the  exercises. 
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Task  Objectives 


Yoa  ar«  In  command  irfa  amatt  craw  oiiboarda  Navy  afilp.  Vdusr  task  1$  to  prefect  yoor 
sblt^tresn  attack  Yon  do  this  fei^  monitorings  radar  sersan  that  shows  afi  ths  ships  and 
aircrali  in  the  vicinity  of  your  ship. 

His  ships  and  aircraft  around  you  nruiy  all  ha  frlandiy^  cm*  s<»na  of  them  might  ba  hostiia« 
Vdutmust  attdit^  to  datdmina  who  might  p<we  a  throat  td  your  ship,  and  taka  maastiras 
to  wardthmn  away.  As  a  last  rescMt>  you  may  command  your  amv  to  firs  on  a  ship  cm* 
arcraft  that  Is  threatening  your  sh^. 

You  have  control  over  the  radar  display^  and  you  hava  a  numbar  of  commands  and 
massages  you  can  Issue.  Ail  cd^your  actions  are  pcaf  ormad  fay  clicking  the  iafl  mouse 
button  on  various  s^rtoots  on  the  screen.  When  you  isaoie  a  ccamnand,  you  may  see  it 
chsplayed  In  words,  iaterj  you  may  see  scone  wwds  toat  repres«if  the  response  to  your  order. 

Ihe  radar  screen  Is  iipdataef  periodically,  to  give  you  the  most  cutrent  view  of 
situation. 

The  following  screcois  wlli  provide  you  complete  details  for  pwtorming  this  task 


The  Radar  Display 


This  is  the  radar  dispiay.  The  grey  area  is  land 
the  white  area  within  the  circle  is  ocean. 

Your  ship  is  the  circle  at  the  center. 

There  are  two  ’targets’  displayed  here, 
a  ship  and  an  aircraft. 


Every  target  carries  a  4-digit 
’track’  number  that  uniquely 
identifies  it.  The  aircraft  is  track  1035; 
the  ship  is  track  1238. 

The  straight  line  on  each  target 
is  called  a  ’velocity  leader’. 

Its  length  reflects  the  target’s  speed, 
and  its  orientation  indicates  the  target’s 
heading.  Aircraft  1035  is  heading 
almost  due  south.  270  - 


The  four  blue  numbers  around  the  radar 
circle  are  used  to  determine  a  craft’s 
heading  and  bearing. 

Aircraft  1035  is  heading  175. 

The  bearing  is  the  angle  between  a  craft 
and  your  ship.  Aircraft  1035  is  positioned 
at  a  bearing  of  300  degrees. 


Target  Symbols 


The  symbof  ased  to  depict  a  target  an  the  radar  screen  indicales  whether 
It  is  an  aacreft,  a  s«rta«e  vess^,  era  salwnaiine.  Ihe  symbol  also 
Indicates  whether  the  omit  has  been  Jitdged  totie  IrlemJiy^  hostie,  or  onteicwn. 

The  tabto  below  ehowe  the  nlneiiosslbie  syrr^is. 


Threat  Assessment 

Unknown 

Friendly 

hostile 

AIRCRAFT 

nr" 

rr" 

SHIP 

(surface  vessel) 

C3^ 

or 

O' 

SUBMARINE 
(sub  surface) 

liT' 

v:r 

XT' 

Here  is  a  complete  target  symbol. 

It  is  a  ship  of  unknown  intentions, 
heading  due  west  and  assigned  a 
track  number  of  1039. 


1039 


Clutter 


r\ 


There  is  a  fourth  land  of  target  called  'clutter'.  A  clutter  target  may  be  rerai, 
atich  as  an  oil  dnlilng  platform,  or  If  may  just  be  an  Invalid  bll?  caused  by  atoto^herPc 
conditions.  In  alt  eases,  cluftw'targets  do  not  move,  and  they  show  up  as  friendly 
aircraft  with  a^o  speed  and  aero  altitude.  There  are  ways  to  clear  ciud^  targets  from 
the  screen  If  they  are  distracting. 
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Controlling  the  Radar  Display 


Commercial  air  routes  are  indicated  on  the  radar  as 
dotted  orange  lines.  The  lines  represent  routes  that 
scheduled  airlines  in  your  area  fly.  Note  that  the  display 
of  air  routes  Is  affect^  by  the  radar  Range. 

airport  F,  , 


You  control  the  Range  of  the  radar  display 
by  clicking  on  any  of  the  five  Range  ’buttons’ 
labeled  256, 128, 64,  32, 16. 


The  Range  establishes  the  distance 
represented  by  the  radius  of  the 
radar  circle. 


This  distance  now 
.i$  32  miles. 


Click  on  different  Ranges  now  to  see  how 
the  display  changes.  Note  that  the  one 
target,  track  1236,  does  not  appear  if 
the  radar  Range  is  set  to  1 6,  since  the  270 - 
target’s  range  is  30  miles. 

Then,  click  on  each  of  the  five  boxes 
under  Display  to  iearn  about  these 
display  elements. 


Clickon  Velocity  Leaders 
an^M  rack  Numbers  to 
tu|n  these  display  elements 
di  or  off  for  all  targets. 


Commercial  air  schedules  indicate  when 
air  liners  are  scheduled  to  depart  and  arrive 
at  various  airports. _ 


Departures  from  airport 

P 

FIiT  i 

TO 

TIME 

WD 

408 

airport 

A 

1145 

WD 

117 

airport 

A 

1330 

WD 

005 

airport 

A 

2100 

airport  A 


The  missile  ship  circle 
indicates  the  approximate 
range  at  w  lich  a  hostile 
craft  can  tiunch  a  missile 
at  you.  A  f  ostile  or  unknown 
craft  brea  :hing  this  area  can 
pose  greai  danger. 
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Hooking  Targets 


To  learn  more  about  a  target,  click  on  It. 
This  is  called  ’hooking’  the  target. 


Track:  1055 

unknown 

aircraft 


^pjpbiiig^ 


.  Click  lEhese  boxes  to  update  your  judgment  ofidte 
booked  target’s  irdent.  Tbe  hooked  targG^’e  symbol 
will  change  to  remind  you  of  that  nssesemoot 

At  the  beginning  of  each  eXer<cdse,  your  crew 
has  made  InitlatIudgGmienta  about  the  verioua 
targets.  These  are  only  Ih^r  Initlaf  threat 
assessments,  end  you  should  tiy  to  ccmf  Irm  them. 


270 


Click  on  the  two  targets  shown  here. 

Notice  that  a  beep  sounds,  a  red 
circle  surrounds  the  hooked  target, 
and  information  about  the  target 
appears  in  the  box. 

During  real  exercises,  moving  targets 
will  move  every  5  to  10  seconds,  reflecting 
their  latest  positions.  The  data  displayed 
for  the  hooked  target  will  update  also, 
reflecting  its  current  altitude,  range,  etc. 

Clutter  targets  never  move,  and  slow  moving 
ships  only  change  position  on  the  display  occasionally 


Assume  Range  is  set  to  32  miles 


180 


Warning  Targets 

tti0  ^ci9  is  s  Warning  Iwt,  wiUi  whici*  tsn  warn  tiia  currant  booked  iarget 

Lwel  t  is  lw<dted  larg^to  lilenlif/  anelto  stale  its  inlentions. 

Lev«d  2  asks  the  iarget  to  identic  ANDto  r^tat^e  coiesa  to  avoid  any  confiict  w^th  your  ship. 

Lev^  $  t^ls  the  target  that  you  may  fire  upon  him  It  he  does  mA  ciear  the  area. 

There  are  twoeommuttfeaticm  channels  OB  which  to  issue  a  wam^! 

The  MAP  channel  is  Military  Air  Pefense,  whicli  military  shps  and  airmaft  usuariy  monitor. 

The  iAP  channel  Is  Intsroatlonal  Air  D^wise,  which  most  cwnmwclal  atrfmws  and  sbipa  irtonitm. 

You  can  Issue  a  warning  on  one  channel^  or  both  channels  (mie  at  a  time}. 


Keep  in  mind  that  the  target  may  not  be  listenin, 
to  the  channel  you  use  to  send  your  warning,  or 
a  radio  malfunction  might  prevent  transmission 
or  reception  of  the  warning,  or  his  radio’d  respons' 

Also  note  that  the  target 
may  be  deceptive  about 
his  identity  and/or  intentions. 

Now  click  on  the  various 
warning  buttons  to  see 
the  warning  being  issued 
{targets  don’t  respond  in 
this  example). 


If  th«  target  responds,  his - - 

response  would  appear  here  after 
about  3  0  seconds • 


_ 180 _ 

Onidentlfied  aircraft  on  a  course  of  283  degrees,  speed  240  toots,  altitude 
7500  feet,  position  29  degrees,  20  minutes  N;  50  degrees,  15  minutes  E. 

This  is  U.S*  Navy  warship. 

Your  intentions  are  not  clear;  request  you  identify  yourself  and 
immediately  alter  course  to  remain  clear  of  my  position,  over. 
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Clearing  emd  Restoring  Targets 


iti  sdddil^  to  Warningd^  you  can  commanttc  u»ing  the  boxes  shown  below 

You  issue  b  c^Xssnand  by  olic^ng  on  S  box  wib):  the  iOR  mouse  button. 

aear  Targ^  Dfsglsy  wai  romoveths  eunentty  Iibb1(edt«rget#<»tii  the  screen. 

Use  this  ciMTunend  to  clear  cluttortarabfs  g  they  am  too  tOslracffeng. 


Use  this  ciMTxnand  to  clear  cluttortaigels  gth^  amtoo  tOslracffeng. 

To  restcHO  a  (xwiiious^  eimred  targets  oh  Restom  Ta-get. 

This  will  bong  themost  recently  cleared  target  badhto  the  screen.  Each 
cilck  on  thfo  button  brings  back  another  {>revlbus1y  cteared  target. 

Now  click  on  Clear  Target  Dii^lay  and  Restore  Ti^get  to  see  these  actions* 


Coriteef  Tower" 


RlquefrYiM 


Defend  Ship 


Identifying  Targets 


Wi}ii«  a  target  might  identify  hima<«  tn  reap<«iae  to  a 

two  other  eommands  glw  more  reOaUe  hiTOimatlonr  if  coRdili<meeliow. 

Contact  Tower  sertda  a  radio  mesaage  toah  mrport  conhot  lower,  a^ng 
if  there  »  a  oommert^l  aWiner  In  the  vicinity  of  the  hm^ed  targ^. 

The  tower  will  ad^ae  y<a»  if  there  Is  such  an  alrJiner  In  dwl  iocanon,  after  • 
atxMut  a  hatf  minute  <if  it  receives  your  message}. 

Request  tftsual  ID  dsects  yoUrmwto  use  high  powo'ed  sighting  mstrumente 
to  Identify  the  hoohed  tar^,  if  there  is  sufficient  daylight,  the  weathw 
condftiona  ahow,  and  tbs  hooked  targ«  Is  within  SO  mfles  raogs,  your  cmw 
will  rOitim  an  identificail<m  after  about  to  ssccnds. 

Now  click  on  Contact  Tower  and  Request  Visual  P  to  see  these  actions. 


CIMrTirgWDTipIy^^^ 


^  V  A# 

6^ 


Ilium  ihatsTargst 


FireWarningShdIs' 


Bridge,  can  you  make  a  visual  identiticatlon  of  aircraft  at  bearing  : 
degrees;  altitude  12000  feet,  range  about  30  miles? 


(a  response  will  appear  here  after  some  delay) 


Acting  on  Targets  ^ 


:  Tltrae  commancEs  th»  liook«d  t«rg^  <irr«e%. 

UlMDilnai?  Targel  ^pomiDands  your  aravif  to  lock  yottr  |ire-6<»n|rQl  radar  coito  the  hooked 
:  tarfi^,  ii^h  l«  a  preparat<^  toac^oaBy  IBring  <m  hr  h  the  target  la  a  military  waft 

i  (IFF  mode  la  1,  ^  or4K  It  will  know^  you  are  luaimrlng  to  fire  at  It. 
rit  may  or  may  not  turn  away  In  respoeae. 

I  Fire  Wammg  commands  your  drew  tohre  near,  but  nOI  at,  the  hoolred  target 

:  This  will  alert  any  approaching  aircraft  wahip  that  yw  will  fire  at  h  If  h  does  notturn  away. 

Defend  $hlp  commands  your  crew  to  fire  at  the  hooked  largely  desf  trying  It  If  possibler 

.  Yois  crew  will  respond  to  fheseorders  in  IS  to  30  seconds, 

:  Theseactlohs  are  sarlotis  ones,  and  ahoutd  only  betaken  tf  you  teartor  the  saMy  of 
yiHirshIp, 

:  Now  click  oh  three  buttons  to  see  the  v^bal  commands  tbi^  produce. 


Besrin,  Pause,  Help,  and  Replay 


TofoltMe  ao  axarcraa,  click  on  tt»  Begin  l>otton,^er  abo«it  10  s^nife,  you  will  aee  llie 
oinpood  fimo  Increasing  {every  Oto  10  seconds^  Bxeielsee  end  ai«<^lteally 
whsn  file  exercise  iime  Umlt  la  reaeked  or  othea*  cendUlona  are  met.  Wiwttne  exw’cjse  ends, 
you  win  Hear  a  beep,  jswd  you  wiH  seen  message dwt  the  exer<use  is  ow. 

If  so,  JUSI  Click <m  any  targets  of  intss-esl  ca-your  ship,  Wi€«  you  are  ready  to  {»oceed  with  the 
next  exercise,  click  on  B^in  agaia. 

Pause  *  , 

If  th€»e  Is  a  Pause  button  shown,  you  have  the  option  to  pause  cweacises  at  any  time.  This 
stops  Hms  ao  that  you  can  do  <rthw  things  before  resumming.  Toresum^  click  on  the  same 
button,  now  labeled  Reaume. 

If  the  Hirfp  iHJtton  af^jeara,  you  can  click  on  it  to  come  to  the  instrucficma  Tc^ks  list,  and 
hwn  there  to  any  of  these  instructional  screens.  To  return  to  fhe  exercise,  click  w  ^ 

Return  ioT<^lc  List,  at  die  bottom  of  each  help  semen,  then  click  on  Return  to  Exercises, 

g  you  have  the  i^ion  to  replay  exercises,  press  the  Y  key  aft«  an  exweise  has  tOTninated. 
You  will  t^bsenre  a  Rei^y  box  on  the  scremt.  Click  on  Begin,  and  watch  the  problem  replayed. 


Exercise  Conditions  and  Results 


£x^cis0  Oondlltons 

Thft  co«tdlitioit«  ih&t  dxtet  dyring  <i«t^dy6d  i»  th»  iowdr  ML 

earner  the  screem^  Thts  ielis  yea  what  the  weahier  is  Mke  (whi^  affects  your 
ahitify  to  make  visual  kJenffftcatliofls)  and  the  status  ef  ye«r  ship’s  racBe 
equiiwneDf ,  whidh  affects  your  ability  to  commanicate. 

Resuits 

At  ffieend  erf  each  exercise,  you  may  be  ^ven  ait  o|)p(xtunity  to  determine  the 
true  idmitify  and  intention  of  any  ottha  tar^eb*  In  the  exercise.  If  you  are  given  this 
c^ion,  yon  will  be  ixompted  to  click  on  the  targets  that  intwest  you. 

You  might  also  observe  a  sCcreet  ffie  end  <rf  each  exercise.  Consult  your  advisor 
tor  the  Interpretation  of  this  numba% 


For  this  exercise,  your  crew  can  see  aircraft  \ 
below  25,000  feet,  if  they  are  within  20  miles.  \ 
Also  your  ship’s  radio  equipment  is  working,  \ 
so  you  can  transmit  warnings  and  communicate  ' 
with  land-based  towers.  If  your  receiver  were  bad, 
you  could  still  issue  warnings,  but  you  wouldn’t 
receive  any  radio  responses. 


Conditions: 

Ceiling:  25000  feet 

Visibility:  20  miles 

Ship’s  transmitter  operational 
Ship’s  receiver  operational 


Target  Symbols 


file  (teedio  a  la^ef  «« tha  rddar 

U'mm  alrarat^  a  $wfac«  ve«»al,  er «  subroarina.  ^a  ayrol^  ulfo 
likdlicataa  whafbar  lha  eraft  ha*  bean  Judg^  lolaa  Iriatidiy^  hodtta,  «*  ootenowa. 

::1^ha  ttdila  ahomia^^t^^^ 


t . . . 

Threat  Assessment 

UHKnown 

hnenaiy 

hiosiiie 

AIRCRAFT 

nr" 

SHIP - 

(surface  vessel) 

SUBMARINE 

<5^ 

(sub  surface) 

vjT" 

Here  is  a  complete  target  symbol. 

It  is  a  ship  of  unknown  intentions, 
heading  due  east  and  assigned  a 
track  number  of  1039. 


1039 


Clutter  '  ' 

^era  fa  a  fourth  kind  of  target,  paiiad  ^ciutter',  A  clutter  targ^  may  be  r€«t, 

aucb  aa  an  oW  dHlimg  platform,  or  it  may  |«s1  be  an  mvatkf  bl|>  oaaaed  by  abno^herfc 

^tididon^  in  all  cases,  clutt^'taiitfia  do  not  m«re,  and  they  show^d^^^ 

aircre^  with  a»fo  spa^  and  zero  altitude.  The^a  ara  ways  to  clear  etuttar  targets  h'om 

the  screen  if  they  are  distracling. 
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Appendix  F 

CIC  Web  Site 


The  following  pages  are  screen  prints  of  the  CIC  Web  site: 

http://www.fcs.net/dtowne/default.htm 


Tactical  Decision  Making  Simulation  and  Research 


file:///DIAVEBSnJFF/CICSite/Cic.htm 


Tactical  Decision  Making  Simulation  and  Research 

...  a  simulation  environment  which  facilitates  experimentation 
in  human  and  machine  learning  of  complex  real-time  tasks 


Please  be  patient ...  this  is  a  graphic-intensive  presentation. 


Main  Topics 

•  Overview 

•  The  task  environment 

•  The  operator's  decisions  and  actions 

•  The  scenario  authoring  features 

•  Research  features 

•  Instructional  capabilities 

•  Download  tlie  files 

•  Development  of  the  simulation  system 


Overview 

The  Tactical  Decision  MaJdng  simulation  system,  or  CIC  for  short,  executes  a  real-time,  interactive 
simulation  of  an  AEGIS-like  radar  system  on  board  a  military  ship.  The  task  concerns  maintaining  the 
safety  of  one’s  own  ship  by  monitoring,  communicating  with,  and  acting  upon  various  air  and  sea  craft  in 
the  area.  The  tactical  decision  maker  executes  commands  via  mouse  actions.  These  commands  are  then 
shown  textually  in  a  'communication'  area  of  the  screen.  Verbal  responses  to  the  decision  maker's 
commands  are  also  shown  in  this  area  -  these  may  be  confirmations  from  other  crew  members  or  answers 
from  aircraft  and  ships  that  have  been  contacted  by  the  decision  maker. 

During  the  conduct  of  an  exercise  the  various  ships  and  aircraft  move  about,  some  in  cooperative  response 
to  the  commands  issued  by  the  decision  maker,  others  perhaps  in  more  hostile  postures.  Depending  upon 
the  intentions  of  the  craft  involved  in  a  particular  exercise,  some  aircraft  or  ships  may  attack  the  ship. 

In  summary,  the  CIC  system  is: 

1.  an  authoring  system  for  rapidly  producing  real-time  tactical  exercises; 

2.  a  simulation  of  a  shipboard  radar  that  is  tracking  surrounding  aircraft  and  ships; 

3.  a  simulation  of  individual  air  and  sea  craft  having  intentions  unknown  to  the  operator;  and 

4.  a  research  tool  capable  of  generating  exercises  and  recording  detailed  performance  data. 

. . 

The  Task  Environment 

The  simulation  consists  of  a  radar  display  depicting  nearby  land  masses,  aircraft,  ships,  and  radar  clutter. 
The  radar  display  presents  an  'overhead'  view  of  the  area,  allowing  the  operator  to  assess  the  range  and 
bearing  of  each  track.  In  addition  the  heading  and  approximate  speed  of  a  track  is  displayed  via  a  'velocity 
leader'  (line). 
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Tactical  Decision  Making  Simulation  and  Research 


rile:///DlAVEBSTUFF/CICSiie/Cic.htm 


Problem:  o 

CaNDITlQNS: 

Ceiling;  BOOO  feet 
Visibility  B  miles 
Ship's  transmitter:  operational 
Sliip'  s  receiver :  operational 


Unidentified  surface  vessel  cm  a  course  of 
219  degrees^  speed  BO  knots^  positicm  30 
degrees,  13  minutes  N;  BO  degrees, 

13  minutes  E. 

this  is  05  Navy  Warship. 

Reguest  you  idratify  yourself 
ancl  state  your  intentions,  over. 


The  display  is  updated  approximately  every  10  seconds,  to  reflect  the  current  position,  bearing,  and 
heading  of  all  the  surrounding  aircraft  and  ships.  By  selecting  a  displayed  craft  (track)  with  the  mouse,  the 
operator  may  obtain  more  precise  information  about  that  track,  including: 

•  range,  bearing  altitude  (if  air),  and  speed; 

•  current  threat  assessment  (friendly,  hostile,  unknown);  and 

•  latitude  and  longitude. 


The  Operator's  Decisions  and  Actions 
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The  operator's  objectives  are  to  1)  ensure  that  no  hostile  craft  poses  a  threat  to  the  ship,  and  2)  ward  away 
friendly  craft  so  that  they  are  not  endangered  and  do  not  present  distractions  or  concern.  More  specific 
rules  of  engagement  can  be  issued  to  the  operator,  externally. 

To  assess  the  tactical  situation,  the  operator  can  control: 

•  the  range  of  the  radar  display; 

•  the  detail  of  displayed  tracks,  including  velocity  leaders  and  track  numbers; 

•  the  display  of  commercial  airline  flight  paths  and  schedules; 

•  display  of  simulated  radar  clutter;  and 

•  the  assigned  threat  class  (friendly,  hostile,  or  unknown)  of  any  displayed  track. 


Based  upon  the  tactical  status  at  any  time,  the  operator  may  command  the  crew  to  take  action  concerning  a 
designated  track.  The  operator  may  issue  any  of  the  following  commands: 

•  attempt  a  visual  identification  of  the  designated  track; 

•  radio  a  warning  to  the  designated  track  (three  levels  of  warning  severity  are  available); 

•  contact  a  land-based  air  control  facility  for  information  about  the  track; 

•  fire  warning  shots  at  the  craft; 

•  illuminate  the  craft  with  fire-control  radar; 

•  defend  the  ship  by  firing  upon  the  threatening  craft. 
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As  commands  are  issued,  they  appear  in  the  communication  box  shown  here.  Verbal  responses  from  other 
aircraft  and  ship  display  here  as  weU. 


The  Scenario  Authoring  Features 

Tactical  scenarios  are  authored  by  'direct  manipulation'  rather  than  via  computer  programming  or  scripting. 
To  author  a  new  scenario,  the  experimenter: 

1.  drags  aircraft,  ship,  and  clutter  symbols  onto  the  radar  display,  to  indicate  their  initial  positions; 

2.  sets  initial  headings,  speeds,  and  altitudes  (if  air)  of  the  various  craft,  with  these  controls: 


Heading  Speed  Mitude 

Time 

> 

> 

•: 

'i 

1 

;  i 

.. 

:  1 

1 

•  i 

227  525  32S00 

0 

3.  assigns  to  each  craft  its  true  identity,  intentions  (friendly  or  hostile),  and  radio  capabilities; 
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Target:  t32  air  : 


Self  ID:  iQ6l  coiwercial  airliner 
ViSUai  ID:  |Q6|  cotmerclal  airliner 
Identity:  |Q6I  cnminercial  airliner 

Will  Fire  rno~l  Will  Heed  Warning  l  yes  j 
IFF  Mode:  m  IFF  Code:  iOOOOl 
Receiver:  iOK  I  Transmitter:  [ 

Monitoring:  lAD  H  MAD  jB 
Track:  1  1125  \ 


4.  sets  the  weather  conditions,  operability  of  ship's  communications  systems,  time  of  day  of  the 
exercise,  exercise  termination  conditions,  and  airport  names; 


Scenario  Configuration 


Ship  Systetki 


Atmospheric  CondiOons 

mmem 

Local  Time  at  Start: 


TemtlnaHon  Conditions 

,.fXt  ^ 

1  ; 

"'mm  ^  '  \ 

Shte 

Save  Airport  Names:  YES 


Data  Fite  Write  Interval: 


Save  as  Scenario: 


Get  Scenario: 


Seconds 


Get  Flight  Plan: 
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During  an  exercise,  those  craft  that  are  friendly  and  do  receive  warnings  from  the  operator  will  change 
course  when  directed.  Similarly  hostile  aircraft  and  ships  will  mount  an  attack  if  they  can  achieve  the 
necessary  position.  In  addition  to  these  actions,  various  ships  and  aircraft  can  be  given  'scheduled' 
maneuvers  that  they  will  perform  no  matter  what  the  operator  commands.  To  do  this,  the  experimenter 
maneuvers  any  of  the  ships  or  aircraft  as  if  he  or  she  were  its  pilot  or  captain.  During  presentation  of  that 
exercise,  those  maneuvers  are  duplicated  by  that  craft,  giving  it  an  individual,  independent,  and  possibly 
unpredictable  character. 


Research  Features 

A  number  of  features  have  been  provided  in  the  CIC  Simulation  system  specifically  to  address  research 
objectives.  These  include: 

•  automatic  generation  of  exercises  (either  systemmatic  or  random  variations  of  conditions) 

•  automatic  recording  of  the  operator's  decisions,  and  consequences  thereof,  throughout  the  scenario 

•  automatic  computation  of  the  proficiency  exhibited  by  the  operator,  on  each  exercise 

•  capability  to  substitute  a  computer  model  for  the  human  operator,  to  conduct  research  in  machine 
learning 


Instructional  Capabilities 

While  the  CIC  Tactical  Decision  Making  system  was  not  developed  specifically  to  serve  an  instructional 
role,  it  supports  a  number  of  relatively  powerful  instructional  functions,  including: 

•  a  replay  capability  that  allows  a  learner  or  instructor  to  play  back  any  previously  completed  exercise 
for  analysis; 

•  a  pause/resume  function  that  allows  scenarios  to  be  paused  during  discussion  of  the  tactical  issues; 

•  a  time  'warp'  control  that  allows  scenarios  to  be  slowed  or  accelerated  at  any  time;  this  allows 
learners  to  pass  by  uninteresting  phases  of  a  replayed  scenario  and  to  concentrate  on  the  most 
instructive  phases. 

•  a  'front  end'  orientation  phase  which  instructs  the  novice  in  performing  the  task.  While  this  is 
intended  only  to  achieve  marginally  proficient  performance  in  new  research  participants,  it  can  be 
extended  to  address  more  intensive  proficiency  issues 


Download  the  Files 


These  files  and  associated  documentation  are 
available  for  use  by  ONR  research  contractors. 


The  RIDES  run-time  simulation  engine  (sRIDESI 


NetScape  users:  right-click  on  the  following  files, 

then  select  Save  This  Link  as ....  The  CIC  Simulation  files... 

•  CIC  Version  2.7.  Only  available  to  Hybrid  Learning  Program  contractors. 

[361  KB;  uncompress,  rename  CIC  If  you  like] 
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•  defaults  [7  KB;  rename  rldes_defaults] 

•  testml  [25  KB;  only  used  in  machine  learning  research] 


Sample  ASCII  files  that  you  can  tailor...(all  are  small) 


A  sample  session  plan  [reneune  SessionPlan] 

Sample  aircraft  and  ship  descriptions  [rename  CICDescriptions] 


Sample  airport  names  [rename  portNames] 
Sample  configuration  1 
Sample  configuration  2 
Sample  configuration  3 
Sample  configuration  4 
Sample  configuration  5 


good  for  building  large  exercises 
good  for  building  moderate  exercises 
good  for  building  small  exercises 
a  commercial  airliner  approaches 
a  hostile  aircraft  approaches 


The  User  Manual 

•  User  Manual  for  Word.  April  1997 


Development  of  the  Simulation  System 

The  simulation  system  was  developed  under  Q>iR.funding  to  support  the  Hybrid  Learning  ProiecL 
(password  required)  a  research  program  concerned  with  both  human  and  machine  learning  of 
complex  tasks.  That  project  was  initiated  by  Dr.  Susan  Chipman  and  is  now  managed  by  Dr.  Helen 
Qigiey. 

The  simulation  was  developed  by  Dr.  Douglas  Towne.  at  Behavioral  Technology  Laboratories. . 
University  of  Southern  California. 

The  underlying  simulation  engine  is  a  portion  of  the  RIDES  simulation  authoring  system  developed 
at  use,  Allen  Munro  and  Douglas  Towne.  Principal  Investigators. 

RIDES  was  developed  under  Air  Force  funding,  .Tim  Fleming.  Armstrong  Laboratories,  Scientific 
Officer. 


Back  to  Main  Topics 
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